-
-
Notifications
You must be signed in to change notification settings - Fork 140
-
-
Notifications
You must be signed in to change notification settings - Fork 140
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
require() fails to resolve import map to core module (Node.js bug) #425
Comments
This is a bug or limitation in Node.js that is not resolving core modules in import maps when using Please report it in Node. As a side, it's also worth mentioning that the |
Thanks for weighing in @privatenumber, I reported to node. I'm not sure if its worth noting to you that I noticed tsx behaves differently when I add With explicit "module" this particular issue disappeared (I assume because tsx would not use In the tsconfig everything was setup for ESM (e.g. "module": "ESNext") so it surprised me that under the hood tsx would choose to use It also seems to have no problem with ESM-only dependencies even when it apparently chooses Import aliases that Just Work are my top use-case for tsx! Import alias / library path hassles and issues with Nx are exactly what lead me to this project in the first place! background context of the use-case The affected project is an Nx monorepo that has web apps, shared libraries, and a cli app used for administration and by ci/cd. In this typical Nx configuration there is a In my case my cli lib (e.g. Also typical of Nx projects in this configuration, the cli lib has its own a When running tsx I pass it the I don't understand why tsx would fail to resolve the import path aliases in this case with "module" in package.json. |
If it's a bug, feel free to file an issue.
tsx doesn't read that value. It could preserve the ESM, but then Node would error that it can't handle ESM in a CJS context (defined by your package.json#type). Feel free to file an issue to emit a warning here.
Easing the ESM migration in Node is one of tsx's biggest selling points. (Also, I don't mean to be rude but please keep your comments short and concise.) |
@privatenumber No worries, I wasn't sure if you would consider the differing behaviour to be a bug or not. I will leave it for now. Good to know that tsx doesn't consider Sorry for writing out the use-case with Nx and if that was too verbose. I've found reporting issues with a monorepo in the mix a lot of project contributors weren't familiar with the differences. Thanks a million for your work on tsx! |
Closing as this is a Node bug unrelated to tsx. |
Are you sure? Is there an open Node.js but that you can link here? |
There's a reproduction and Node issue linked above. Locking this but if you're able to prove this is a bug in tsx, feel free to re-file. |
Precheck
Problem
tsx
fails to import packages that in turn use subpath imports with the following error:TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
Subpath imports is a feature dating back to node v12.
Docs reference (current LTS): https://nodejs.org/api/packages.html#subpath-imports
Example error output:
A noteworthy aspect of subpath imports is that they have a
#
character for the internal "package" name. I don't know about the inner workings of tsx however I suspect this could be relevant to the issue and why its not interpreted as a correct file url.Expected behavior
tsx
should Just WorkTM in this case and support packages that use this feature without issue.Example
code with p-limit v5 (refer to the stackblitz repro) should run correctly i.e. without error just as it would with p-limit v4 which does not have subpath imports.
I think
p-limit
is a very representative example of a package that any developer would expecttsx
to be able to support: 84,485,661 weekly downloads, and as a sindresorhus package it is 100% ESM.Here is the v4 vs. v5 release diff with a hash link to exactly the line of code with subpath import that appears in the error trace:
sindresorhus/p-limit@v4.0.0...v5.0.0#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R2
Thanks for your work on tsx, this project was a lifesaver for me on a project when I first discovered it!
Minimal reproduction URL
https://stackblitz.com/edit/node-pqu7ir?file=index.ts
Version
v4.6.1
Node.js version
v20.10.0
Package manager
pnpm
Operating system
Linux
Contributions
The text was updated successfully, but these errors were encountered: