5 ms·

No, you were using non-standard ESM modules (compiled to CommonJS defined by babel) Typescript recently added support for ESM compatible with node.js see "modul

No, you were using non-standard ESM modules (compiled to CommonJS defined by babel) Typescript recently added support for ESM compatible with node.js see "module": "node16"[1][2] The Whole ESM saga is clusterfuck, not much better than python 2 -> 3 migration. Large node.js codebases have no viable path to migrate, and most tools still cannot support ESM properly[3]. Stuff is already breaking because prolific library authors are switching to ESM. As someone that maintain large part of TS/JS tooling in my day job, I absolutely despise decisions made by node.js module team. My side projects are now in Elixir and zig because these communities care about DX. [1] https://nodejs.org/api/esm.html#differences-between-es-modules-and-commonjs [2] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html [3] https://github.com/facebook/jest/issues/9430

redox99 4y ago
Yeah it's pretty ugly. This whole thing is a prime example of those cases in which maintainers for mostly arbitrary reasons decide on something and then absolutely ignore all the massive negative feedback they get for this. They'll cite some nebulous technical reasons of why it has to be this way, but if you offer a PR that actually solves the issue that the community complains about, they'll reject it. In this case they decided that tsc won't transpile imports. They just did and it's "policy" and it can't be changed. It doesn't matter if it is awful for compatibility, developer experience, etc. It's just the policy. Issues will be closed. And no, even an optional flag to transpile imports is off the table, even if you write the PR for it. There are many many issues opened related to this in github, but to give an example https://github.com/microsoft/TypeScript/issues/16577 https://github.com/microsoft/TypeScript/issues/16577
- Chyzwar 4y ago
  It is complicated but most user anger should be directed to node.js module group[1]. TS is forced to follow node.js standard. [1] https://github.com/nodejs/modules/issues/323 https://github.com/nodejs/modules/issues/323
  - iainmerrick 4y ago
    Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem. This explanation in the comments makes sense to me: Transpilers can add the ability to add extensions at compile time, so a specifier like './file' can be rewritten to './file.js' during compilation along with whatever else is getting converted by the transpiler. It seems sensible for Node to expect fully-qualified imports, just like a browser would. And (to me) it seems sensible that in a language like TypeScript you should be able to import “foo.ts” and it have it transpiled to the correct filename. Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node.
    - Chyzwar 4y ago
      Browsers never required extensions, see https://unpkg.com/ https://unpkg.com/ You can load scripts in browser just fine without extension. > Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node. I think they should provide a better explainer. But node.js resolution algorithms is already incredibly complicated, and adding path rewriting to typescript is not going to make it better. There are things like dynamic import and third part libraries. Typescript would need to either analyze whole of project node_modules or bundle custom runtime resolver like webpack breaking compact with deno and friends. Imagine situation: import lib from 'somelib/subpath' How TS would know that some lib have extension in subpath and it need to add/remove js ext? https://nodejs.org/api/packages.html#extensions-in-subpaths https://nodejs.org/api/packages.html#extensions-in-subpaths What if typescript is running in deno/bum or wasm? > Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem. My conclusion is that successful projects without BDFL are prone to corporate takeovers. You have people that working in corporations without writing code and want to make political career as "core" team member of project.
tobyhinloopen 4y ago
Elixir + Phoenix is so much better :) we have some apps running in production, some are 6 years old.

redox99 4y ago

Yeah it's pretty ugly. This whole thing is a prime example of those cases in which maintainers for mostly arbitrary reasons decide on something and then absolutely ignore all the massive negative feedback they get for this. They'll cite some nebulous technical reasons of why it has to be this way, but if you offer a PR that actually solves the issue that the community complains about, they'll reject it. In this case they decided that tsc won't transpile imports. They just did and it's "policy" and it can't be changed. It doesn't matter if it is awful for compatibility, developer experience, etc. It's just the policy. Issues will be closed. And no, even an optional flag to transpile imports is off the table, even if you write the PR for it. There are many many issues opened related to this in github, but to give an example https://github.com/microsoft/TypeScript/issues/16577 https://github.com/microsoft/TypeScript/issues/16577

Chyzwar 4y ago
It is complicated but most user anger should be directed to node.js module group[1]. TS is forced to follow node.js standard. [1] https://github.com/nodejs/modules/issues/323 https://github.com/nodejs/modules/issues/323
- iainmerrick 4y ago
  Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem. This explanation in the comments makes sense to me: Transpilers can add the ability to add extensions at compile time, so a specifier like './file' can be rewritten to './file.js' during compilation along with whatever else is getting converted by the transpiler. It seems sensible for Node to expect fully-qualified imports, just like a browser would. And (to me) it seems sensible that in a language like TypeScript you should be able to import “foo.ts” and it have it transpiled to the correct filename. Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node.
  - Chyzwar 4y ago
    Browsers never required extensions, see https://unpkg.com/ https://unpkg.com/ You can load scripts in browser just fine without extension. > Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node. I think they should provide a better explainer. But node.js resolution algorithms is already incredibly complicated, and adding path rewriting to typescript is not going to make it better. There are things like dynamic import and third part libraries. Typescript would need to either analyze whole of project node_modules or bundle custom runtime resolver like webpack breaking compact with deno and friends. Imagine situation: import lib from 'somelib/subpath' How TS would know that some lib have extension in subpath and it need to add/remove js ext? https://nodejs.org/api/packages.html#extensions-in-subpaths https://nodejs.org/api/packages.html#extensions-in-subpaths What if typescript is running in deno/bum or wasm? > Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem. My conclusion is that successful projects without BDFL are prone to corporate takeovers. You have people that working in corporations without writing code and want to make political career as "core" team member of project.

tobyhinloopen 4y ago

Elixir + Phoenix is so much better :) we have some apps running in production, some are 6 years old.