5 ms·

Every TypeScript project I have worked on either: 1) enforces no extension, e.g. “utils/foo”, or 2) allows TS extensions, e.g. “utils/foo.ts” I have never im

Every TypeScript project I have worked on either: 1) enforces no extension, e.g. “utils/foo”, or 2) allows TS extensions, e.g. “utils/foo.ts” I have never imported a TS file using a JS extension. Maybe your woes could be fixed with a configuration change?

dickfickling 4y ago
have you worked on Typescript projects using ES modules? What you’ve described is the status quo for CommonJS modules, but doesn’t work when you switch to ESM (afaik, at least)
sebdufbeau 4y ago
From my understanding, this is a fairly new predicament, for projects that target ESM (type module in package.json) instead of the default CJS
cypress66 4y ago
And that's how it should work imo. But if you enable esm (which you might need in the future because of packages being esm only) you can't use those, only .js. That's because typescript developers are dead set that they don't want to transpile the imports, they just want to copy paste them into the resulting file when running tsc.
- conaclos 4y ago
  This could change with an ongoing work to allow ts extension [1]. [1] https://github.com/microsoft/TypeScript/issues/37582 https://github.com/microsoft/TypeScript/issues/37582
  - iainmerrick 4y ago
    That doesn’t look like an issue that’s going to be resolved any time soon. Lots of comments which read like people digging in their heels to preserve the current behavior.
    - conaclos 4y ago
      It was in the 4.9 iteration plan [1], and is now in the 5.0 iteration plan [2]. They also talk of this in a design meeting [3] and a member of TS team seems committed to it. [1] https://github.com/microsoft/TypeScript/issues/50457 https://github.com/microsoft/TypeScript/issues/50457 [2] https://github.com/microsoft/TypeScript/issues/51362 https://github.com/microsoft/TypeScript/issues/51362 [3] https://github.com/microsoft/TypeScript/issues/51302 https://github.com/microsoft/TypeScript/issues/51302
      - iainmerrick 4y ago
        Well, I would love to see it, so I hope I’m wrong and you’re right!
  - bakkoting 4y ago
    You'll only be able to use that if you are using the non-default `--noEmit` configuration, which requires the use of some other tool to strip types. Even after that change, using `tsc` to strip types will still force you to write `.js` in your imports.
Chyzwar 4y ago
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
tobyhinloopen 4y ago
No, it’s new, to comply with new stuff from nodejs. You can likely change it with a config, but do note that importing using .js will be the new standard way of doing things and by changing it through configuration you’re chosing to not follow the new standard. It’s a complete mess IMO. Every project uses a different way to handle modules and there’s a lot of rough edges.

dickfickling 4y ago

have you worked on Typescript projects using ES modules? What you’ve described is the status quo for CommonJS modules, but doesn’t work when you switch to ESM (afaik, at least)

sebdufbeau 4y ago

From my understanding, this is a fairly new predicament, for projects that target ESM (type module in package.json) instead of the default CJS

cypress66 4y ago

And that's how it should work imo. But if you enable esm (which you might need in the future because of packages being esm only) you can't use those, only .js. That's because typescript developers are dead set that they don't want to transpile the imports, they just want to copy paste them into the resulting file when running tsc.

conaclos 4y ago
This could change with an ongoing work to allow ts extension [1]. [1] https://github.com/microsoft/TypeScript/issues/37582 https://github.com/microsoft/TypeScript/issues/37582
- iainmerrick 4y ago
  That doesn’t look like an issue that’s going to be resolved any time soon. Lots of comments which read like people digging in their heels to preserve the current behavior.
  - conaclos 4y ago
    It was in the 4.9 iteration plan [1], and is now in the 5.0 iteration plan [2]. They also talk of this in a design meeting [3] and a member of TS team seems committed to it. [1] https://github.com/microsoft/TypeScript/issues/50457 https://github.com/microsoft/TypeScript/issues/50457 [2] https://github.com/microsoft/TypeScript/issues/51362 https://github.com/microsoft/TypeScript/issues/51362 [3] https://github.com/microsoft/TypeScript/issues/51302 https://github.com/microsoft/TypeScript/issues/51302
    - iainmerrick 4y ago
      Well, I would love to see it, so I hope I’m wrong and you’re right!
- bakkoting 4y ago
  You'll only be able to use that if you are using the non-default `--noEmit` configuration, which requires the use of some other tool to strip types. Even after that change, using `tsc` to strip types will still force you to write `.js` in your imports.

Chyzwar 4y ago

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

tobyhinloopen 4y ago

No, it’s new, to comply with new stuff from nodejs. You can likely change it with a config, but do note that importing using .js will be the new standard way of doing things and by changing it through configuration you’re chosing to not follow the new standard. It’s a complete mess IMO. Every project uses a different way to handle modules and there’s a lot of rough edges.