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

Changed moduleResolution to NodeNext #42

Conversation

mattpocock
Copy link
Contributor

@mattpocock mattpocock commented Jun 7, 2024

twoslash-cdn (and possibly other packages in the repo) can't currently be run in a Node.js environment.

This is mainly due to a single import.

So, I updated the root tsconfig.json to use NodeNext, and updated all import paths to follow it.

This will solve my downstream issue.

LMK if you want me to raise an issue to link to, but I figured this was a quick win.

Copy link

netlify bot commented Jun 7, 2024

Deploy Preview for twoslash ready!

Name Link
🔨 Latest commit 41c64e3
🔍 Latest deploy log https://app.netlify.com/sites/twoslash/deploys/6662dfa85036e300087f925d
😎 Deploy Preview https://deploy-preview-42--twoslash.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@@ -93,7 +93,7 @@ export default defineConfig({
} as any

try {
const jiti = JITI(id, {
const jiti = (JITI as any)(id, {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was erroring after this change, but I'm unsure why.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of this: unjs/jiti#244

@@ -5,7 +5,7 @@
"private": true,
"packageManager": "pnpm@9.1.3",
"scripts": {
"typecheck": "tsc --noEmit",
"typecheck": "tsc",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting noEmit inside the tsconfig.json is a best practice, since users of this repo won't always know to run pnpm typecheck and not just pnpm tsc.

@@ -7,8 +7,8 @@
"esnext"
],
"moduleDetection": "force",
"module": "esnext",
"moduleResolution": "node",
"module": "NodeNext",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to change this to Node16 if you like for 'stability', but I think NodeNext is perfectly fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would always prefer "Bundler" - I wonder if there is any downside to it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, Bundler wouldn't have caught my runtime error, because it wouldn't have prompted you to add the .js to the end of the file.

There might be something you can tweak in your unbuild settings to make this work, but NodeNext is always going to be safer and more predictable than Bundler for libraries.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see the problem now. But I am honestly not a fan of the .js extension, especially when all files are actually .ts. Is it possible to have a middle ground where the library extension error can be caught but not force every import to have .js?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure - the only way to trigger this warning is with moduleResolution: NodeNext. I wouldn't advise messing around with allowImportingTsExtensions, since it would probably trigger the same runtime error for me if not transformed.

I'm also not sure whether rollup could catch this error. It has no idea whether typescript/lib/tsserverlibrary is a file (which it is) or a package entrypoint defined via exports. So, it doesn't add the .js extension in the output.

I have to say that having been using the .js extension for a while, it is really, really nice. So nice to know exactly which file is being targeted and keep you in the mindset that you're writing JS, not TS.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also for types-only imports it’s technically correct. In this case not because of Node.js, but because TypeScript dictates this.

In TypeScript 5.3 typescript/lib/tsserverlibrary.js was made an alias of typescript. So all 'typescript/lib/tsserverlibrary' imports can be replaced with 'typescript'.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@antfu Could we merge this, then look for a better solution afterwards? I am currently blocked by this, so having a patch would be pretty useful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattpocock Sorry, I am on a conf and wasn't very responsive. I am still not sure .js is a long-term solution for me (unless @orta has some preference). It's nice as @remcohaszing pointed out - could we have a smaller PR that changes typescript/lib/tsserverlibrary to typescript to fix the runtime error, without adding .js for now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure thing!

#43

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of adding extensions manually to all the files, a plugin like https://github.com/favware/esbuild-plugin-file-path-extensions can be created for unbuild to add the extensions at build time the you can use Bundler module resolution

@antfu antfu closed this in 57ed17a Jun 11, 2024
antfu added a commit that referenced this pull request Jun 11, 2024
@antfu
Copy link
Member

antfu commented Jun 11, 2024

Switched to Bundler in 57ed17a as it's also more closed to the fact that we are bundling the source code. unbuild already generated explicit extension in .mjs file so it the runtime should be strict already.

Thanks for bringing this up.

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

Successfully merging this pull request may close these issues.

5 participants