3 ms·

This isn't going to fix those issues. Those issues aren't due to tsc. They're due to an ecosystem which refuses to recognize the realities of compilation and a

by spion 5y ago

This isn't going to fix those issues. Those issues aren't due to tsc. They're due to an ecosystem which refuses to recognize the realities of compilation and add first class support for it. Its also due to an ecosystem willing to break compatibility (and not just backward compatibility but compatibility to other tools) at the drop of a hat. For example, the main reason I've seen why people began using bundlers for node recently is the fact that a lot of modules transitioned to pure ES6 without CommonJS support. In most projects, this means you have to use a bundler to be able to import those modules, or switch your entire codebase to ES6 (which is non-trivial due to changes in import path semantics). If it weren't for the above, you could just run `tsc` to get a `.js` file in `dist` for every `.ts.` file in `src` and run node on those.

afavour 5y ago
> They're due to an ecosystem which refuses to recoginze the realities of compilation and add first class support for it. IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.
- dmitriid 5y ago
  > Compilation should result in WebAssembly It... It really shouldn't. Especially not if the target is the browser as the bridge between WebAssembly and the rest of the browser is still "just pass these arrays of integers around".
- jeremyjh 5y ago
  I do not think that is a goal of either project; I’m not even aware of a POC JavaScript to WASM compiler. AssemblyScript couldn’t work without strong typing semantics and doesn’t support many typescript features.
spion 5y ago
Of course, using a bundler means you'll face several other unpleasant realities. Like - what about tests, how do they run - source maps support in node being 3rd party and unbearably slow for any medium sized project - edit: this has been fixed somewhat recently https://nodejs.medium.com/source-maps-in-node-js-482872b56116 - only the 3rd party bit, not the slowness bit https://github.com/nodejs/node/issues/41541 - also applicable when not bundling, albiet fewer reprcutions to turning off source maps - poor native (C++) modules support in bundlers - modules with really dynamic `require` statements being supported at varying levels by varying bundlers

by spion 5y ago

afavour 5y ago

> They're due to an ecosystem which refuses to recoginze the realities of compilation and add first class support for it. IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.

dmitriid 5y ago
> Compilation should result in WebAssembly It... It really shouldn't. Especially not if the target is the browser as the bridge between WebAssembly and the rest of the browser is still "just pass these arrays of integers around".
jeremyjh 5y ago
I do not think that is a goal of either project; I’m not even aware of a POC JavaScript to WASM compiler. AssemblyScript couldn’t work without strong typing semantics and doesn’t support many typescript features.

spion 5y ago

Of course, using a bundler means you'll face several other unpleasant realities. Like - what about tests, how do they run - source maps support in node being 3rd party and unbearably slow for any medium sized project - edit: this has been fixed somewhat recently https://nodejs.medium.com/source-maps-in-node-js-482872b56116 - only the 3rd party bit, not the slowness bit https://github.com/nodejs/node/issues/41541 - also applicable when not bundling, albiet fewer reprcutions to turning off source maps - poor native (C++) modules support in bundlers - modules with really dynamic `require` statements being supported at varying levels by varying bundlers