Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any Plans for ESM File Extensions? #22

Closed
shellscape opened this issue Oct 25, 2023 · 3 comments
Closed

Any Plans for ESM File Extensions? #22

shellscape opened this issue Oct 25, 2023 · 3 comments

Comments

@shellscape
Copy link

One thing that has always burned us TS developers is that we're either forced to use file extensions (which are super janky in TypeScript, having to use .js extensions in imports) or to use a different built tool other than tsc (e.g. tsup or esbuild).

The TypeScript team had adamantly refused to support automatically adding file extensions (see: microsoft/TypeScript#42151, microsoft/TypeScript#42813)

IMHO this is the largest bit of friction for TS developers that are shipping packages for CJS and ESM support.

@isaacs
Copy link
Owner

isaacs commented Oct 25, 2023

The way to do this is to write your import statements as they will appear in the final code.

So, if you're in src/x.ts and you want to include the file at src/y.ts, you do import './y.js', because the file at y.ts will build to y.js and tsc doesn't change the literal string that is in your import statement. If you want the file at src/z.mts, then that's ./z.mjs, etc.

I actually agree with the TypeScript team here. It's really not that much of a burn, tbh, and it cuts out a signfiicant source of complexity and bugs by just leaving the strings untouched in the build. (Ie, it's simpler and more deterministic to figure out where the types are from a .js path/url, and then never touch them again, rather than it is to figure out what the resulting import should be from a .ts path in all possible cases. This is extra true in the case of tsx.)

If tsc changes this, then yeah, it'll change in tshy, because tshy just runs tsc to compile the code. But tshy isn't a compiler, it's a sort of meta build script management thing, so it wouldn't be appropriate for it to have an opinion on things like import paths.

Your preferences are malleable. Find it in your heart to appreciate the wisdom of TSC's choice in this. There are so many things in this world to be annoyed by. You don't need this one. Your life will improve if you stop worrying and learn to love the .js extension.

@isaacs isaacs closed this as completed Oct 25, 2023
@shellscape
Copy link
Author

That was a solid reply right up until the last paragraph. Good context for people already unaware of the nuance of the situation, but I'll continue to disagree that the prescribed dogma from the TypeScript team is law. Best of luck on the project.

@isaacs
Copy link
Owner

isaacs commented Oct 25, 2023

Thanks, lol 😂

Not intended to be preaching dogma or making laws. Just some advice, sharing an approach that I've found helpful. If type checking is less important to you than being able to omit the extensions from your import statements, ok, you have other options. Personally, I prefer to use tsc, since it's the official standard and has the most support behind it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants