-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
order rule should support "node:" protocol for imports #2035
Comments
See also the eslint-plugin-unicorn rule prefer-node-protocol. |
Support it in what way? I released an update to Separately, I think a rule like "prefer-node-protocol" is in fact insanely harmful, because package authors should never use it for the foreseeable future, due to backwards compatibility. |
Sorry, I should have been clearer in my report. The specific problem I have with the Here’s an example:
When I lint this, I get the following warning:
The Regarding backward compatibility, according to the documentation for |
Packages shouldn’t be dropping support for a node version just because it’s not LTS. Thanks for the link tho; i didn’t realize it had been backported. I’ll have to update is-core-module to cover 12 and 14 for these kind of imports. What version of node are you using eslint with? (note that if you’re using vscode, it bundles its own copy of node). Until i make the is-core-module change, only in node 16 will eslint properly recognize node: imports. |
I’m using node v16.0.0 on Linux (Fedora 33). I’m not using VSCode. |
I double checked; |
Can you confirm which version of |
From documentation |
@nicolashenry yes, but that's the "imports" section of the docs. Try it yourself - |
I don't get your point, imports are working fine with 14.15.5: import * as fs from 'node:fs';
console.log(fs !== undefined); $ node --version
v14.15.5
$ node test.js
true Who cares about |
This plugin doesn't handle native ESM in node particularly; like virtually the entire JS ecosystem, it's built for transpiled ESM. Thus, If you happen to be authoring native ESM, this plugin does not yet support that. |
@ljharb @nicolashenry Node v16 supports the @ljharb I don’t directly use is-core-module, but |
@adp-psych aha, oops :-) #1926 isn't released yet, however, which means that |
@ljharb
|
@adp-psych yes, but it uses |
@ljharb I see what you’re saying; but after running |
@adp-psych and just to reiterate, this is with node 16, with eslint, on the command line, and |
@ljharb Yes, I think so:
|
Thanks, assuming that changing |
@ljharb I’ve looked into this a bit and it seems that you can mostly fix the problem in
I also wrote some tests for
The only remaining problem is that fixing doesn’t work correctly:
I don’t really understand the code, but it seems that it calculates the |
Hi, |
Same here with uvicorn wanting me to use "node:x" syntax for built-in modules. As for me it is just for scripts and tools so not the project itself. Would be nice to have module support for it. As a workaround I disabled it in eslint with: |
There's not a good reason to prefer the |
What downsides ? If you talk about node compatibility, it is only important for library developers, not for application developers. For advantages, there are some explained in this proposal nodejs/node#38343 which is about to use it by default in node documentation examples. So if you disagree, I suggest you to give your counter arguments to the Node.js team before it is done (for now there are almost only positive reactions). |
I mostly agree, but as @nicolashenry said, it shouldn’t be a problem for applications. |
@iamnapo @ljharb Note that fixing still doesn’t work correctly, as I detailed above. |
@adp-psych I ran the tests without |
@ljharb fyi: This is indeed fixed in |
Please file a new issue if it's not working! |
The
order
rule should support thenode:
protocol for builtin node modules.The text was updated successfully, but these errors were encountered: