-
-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Support Typescript 4.7 "Node16" extension requirements #8993
Comments
Out of curiosity, did you notice improvements? Runtime or Buildtime? |
I have not tested for any build/runtime improvements. However, it does provide some long awaited developer experience improvements. Using the "Node16" module specifier makes Typescript finally use the import/export fields in package.json properly. This is a big help where packages don't use the "main" field because they do not want to indicate backwards compatibility with pre Node 12. Previously, Typescript tooling was usually difficult to set up because of how it failed to recognize newer package.json configurations (that only cater to ESM). I do not use the tsc compiler so I won't see the improvements that the compilation options provide. But the steady move towards proper ESM handling across all tools commonly used in the same toolchain is all I really want to see. |
Thanks for explaining that, appreciate it. |
Running into another issue with Subpath import patterns We can't safely use Vue project that doesn't run because of Vite... Another example, showing tsx running correctly, but vite failing dude to an issue with TS's Node16 module loading support. Resolved TypeScript issue supporting Subpath Imports: I wouldn't call this an enhancement, but a build breaking bug. This issue has caused me to refactor several repos that made heavy use of it. Using ssrLoadModule causes some workarounds to stop working... meaning I have no choice but to refactor the relatively old and well supported Node feature out. |
We've discussed this in the last team meeting and decided to support The rule seems to be that, if the |
As the official Vite plugins are currently packaged using a Psuedo-module format that uses You currently have to import some plugins with Definition using synthetic legacy default export: https://unpkg.com/browse/@vitejs/plugin-vue@3.1.2/dist/index.d.ts |
When will this happen? Currently, my setup syntax highlights my local imports (without ext) as errors, but vite can build / serve them just fine. It's kind of annoying. Or am I missing some nuance of intent? |
This "kind of" works, but requires a full restart of the vite dev server every time a new ts file is created and later on imported from another file with a js extension. |
Description
With Typescript version 4.7, Typescript now has the option to preserve "ES Modules" if
tsconfig.json
specifies:This is a step forward in supporting native ESM in Node from Typescript's direction, but it comes with the requirement that all typescript modules when imported use the
.js
extension.This works all fine and well in Vite when importing typescript modules in
.ts
-files.The problems begin when importing
.ts
-files in.js
,.vue
,.svelte
, and so on.E.g.
See reproducible example: https://github.com/aMediocreDad/vite-import-ts-as-js
Suggested solution
The expectation is that importing
.ts
-files as.js
resolves the file like it does in.ts
-files at the moment (See related "Closed" issue: #3040).Alternative
No response
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: