webpack.common missing - TypeScript config fails to run on ARM64 Mac

[RillJ]

I was trying to get the UI running locally on an ARM64 M3 Mac following the contribution instructions. I ran into a couple of issues and wanted to share them here in case there's an easy fix or if others might run into the same.

I followed the steps up to npm run start:web. Everything installed fine (after applying the Puppeteer workaround for ARM64), but when starting the UI, I got:

Cannot find module '../httptoolkit-ui/automation/webpack.common' imported from ../httptoolkit-ui/automation/webpack.dev.ts

Looking at the repo, the file is actually named webpack.common.ts, so I changed the config reference in webpack.dev.ts to point to that instead.

However, after that, I got a new error from Webpack:

SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: The angle-bracket syntax for type assertions, <T>expr, is not supported in type strip mode. Instead, use the 'as' syntax: expr as T.

It seems Webpack doesn't support TypeScript natively in this setup. I didn't want to start modifying the build tooling (like installing ts-node, changing tsconfig.json, etc.) since this code hasn’t been touched in a while, and I’m not deeply familiar with Node.js/TypeScript internals.

Is there a preferred way to run this on newer machines (esp. ARM Macs)? Or could the webpack config be precompiled or default to a .js file to avoid this?

[pimterry]

There shouldn't be anything specific to ARM64 Macs here, all the webpack & Node setup is platform independent.

I suspect this means you're using a new Node version, which is trying to interpret the TS itself. Node can handle only a limited subset of typescript, which is why this is failing. I think some recent versions have enabled this by default. I haven't touched this in a while, but really it's all supposed to be handled by ts-node, which can handle all normal TS syntax including implicit file extensions etc.

What Node version are you using? I've just tested with Node 22.15 (the latest LTS release) and it works fine, but it looks like Node 23 (the current unstable/non-TLS version) does fail with errors like you describe. In the CI build we're currently building with Node 20.18.1 so that should definitely work.

I am open to updating this setup to support pure type stripping though, there's no particular reason not to, so a PR for that is welcome if you're interested. It's likely a matter of adding in any implicit extensions and replacing <T>expr with expr as T anywhere it's used.