[wruza]

I'd like to use some modern common ground for js/ts development, but the entire toolchain is not ready for this, somehow turning it into chicken/egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to "type":"module" in package.json, which makes webpack.server.config.ts fail because typescript is not ready for type:module until 4.6. I can't even recall now what's with Babel, I guess the same issue, since I'm using it to strip types in development builds. And then there are modules from ESM movement which are incompatible with this state of things. I understand their idea that nothing will move if not kicked further, but I hate it in real production where I can't upgrade because the author said so. Once ESM transition will be done, Deno will get much more modules, I believe. But right now the friction is unbelievable. Idk why they can't just allow all of the things like imports, requires, sync/async, side effects thing at least for a while, to cooperate. It's a matter of a form, not of a content. And there is no reason seemingly why nodejs couldn't make main.js async by default — sync modules would return a resolved promise. There is so much circus in all of that, which makes you pull hairs for weeks of a setup process.

^ I'm bundling server-side for hmr/watch functionality in a monorepo with many cross-side shared code/modules.

[nikanj]

I tried doing Advent of Code in Typescript, and spent entirely too many hours googling circular problems like "I can't use type:module because then ts-node can't load .ts files anymore, but if I don't use it, then require-statements are broken, but ...."

I don't even remember the details, but I remember it all feeling very rickety. I'd never push anything that fragile into production, it didn't even survive 25 days of doing small puzzles without constant nursing

[wruza]

Yep, the same experience and conclusions. I'm afraid of using this in production, because chances are some of the major players would say "well, I'll just kick the can down the road", and I will be dependency-deadlocked for all the time it's in the air.

Meanwhile guys like node-fetch and chalk ask us why don't we just adopt ESM.

[jcelerier]

Reading that makes me so happy to just have to open QtCreator, hit "new project" and get rolling

[wruza]

You can do that with nodejs too, e.g. edit package.json and main.js in vscode, hit hotkey to npm install hit hotkey to run node ./main.js. This is what I'm doing at the day job.

What I'm trying to do there is to have a client and server in the same ./src, hot-reloaded module-wise on "save" only when a relevant part changes, and vscode to typecheck both at the same time. The language similarity is also a goal. It's a little more than just a traditional lazy-compile-restart cycle.

Non-monorepo non-ts-only guys do not experience my issues, because they only have one environment per project (or per src-<target>), and don't try to make their build configs incompatible with other parts of a build system. I tried to push it as far as it could go to evaluate the state of things for writing non-standard slightly different web apps. To make a ts-react app, they just use CRA, for a backend they just use node main.js.

But anyway this shows how interdependent this ecosystem is, instead of being full of orthogonal possibilities.

[pier25]

I still miss being able to do that with Flash.