3 ms·
I went down the ESM rabbit hole, after 2 months I decided to stay away. Main reason is/was I want true monorepos in TypeScript with single DRY type definitions
by desmap 6y ago
I went down the ESM rabbit hole, after 2 months I decided to stay away. Main reason is/was I want true monorepos in TypeScript with single DRY type definitions (so you need to import them to the FE). This alone is with CommonJS already a bigger endeavor but impossible when mixing in ESM for the frontend parts. Nobody should be blamed here because it's so much legacy, so many systems involved, so yeah.
- horsawlarway 6y agoI've been doing this in a personal project. I ended up settling on ts-node as the fix -https://www.npmjs.com/package/ts-node https://www.npmjs.com/package/ts-node Frankly - it does pretty much everything I want it to. I can write code in Typescript and have it feel like there's no build step at all. I can use ESM everywhere - frontend, backend, buildscripts, random tasks, etc - and have no problems. That said - It's not a legacy codebase, and it's only getting hobby level usage (currently serving a few requests a second), so there might be hurdles I'm just not hitting.
- desmap 6y ago> I can use ESM everywhere - frontend, backend, buildscripts, Once you mix commonjs and esm and try to import from one to another, it doesnt work anymore. Since major BE libs are commonjs you'll quickly face this situation. It's not related to ts-node but to ts' core. Besides, I find ts-node not that spectacular, it hides too much moving parts/it's too high level, it might be good for starters but nothing I'd use in production.