-
-
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
Rule import/no-unresolved
raise false positive when there is no main
field in the package.json
#2132
Comments
A package just for the browser still needs node behavior, even if that’s “nothing”, so having it lack a main is a bug. That said, it seems reasonable that when there’s no “main” present, but there is a browser field, that we respect it for the purposes of this rule - although i worry that would hide a bug in the common case. |
I think that it would be better not to demand the
|
Perhaps |
|
There are the same lint errors even when using |
The same error occurs for the p-queue package which I agree that this is rather odd considering what is currently advised on the NodeJS site. |
I'm using
...
"typings": "./esm/vs/editor/editor.api.d.ts",
"module": "./esm/vs/editor/editor.main.js",
... https://github.com/microsoft/monaco-editor/blob/v0.26.1/package.json#L15-L16 |
@LumaKernel that package.json is incorrect. The module field is not a thing, and the lack of main/exports combined with private:true means nobody can, or should be able to, import/require from that package. |
I ran into this with periscopic 3.0.3, which has the following in
Seems like this could also be fixed by support |
@benmccann yep! That ones a valid one, but since it lacks a main (which it should have for back compat support anyways), we can’t resolve it until exports is supported by resolve. |
This is also raised for packages that are typescript definitions-only. import type { Sink, Source } from 'callbag' Rule |
@niieani |
@ljharb yup, simplest reproduction is that line I cited above. Install |
I mean, that package is super broken because it has a "main" that doesn't exist - it should specify That said, we should be using |
All package authored by @sindresorhus will be migrated to pure esm module see article |
@ghoullier yes, i'm aware - and that's very user-hostile and will break a ton of things, including this plugin. I suggest switching to packages that preserve compatibility. |
I have just upgraded a side-project to ESM – it consists of data-processing scripts and a Next.js app for data visualisations. Everything seems to be working with For me, this unlocked Although I have no runtime issues, importing import chalk from "chalk"; // ❌ Unable to resolve path to module 'chalk'. eslint(import/no-unresolved) The other two very similar packages don’t produce any ESLint errors. Here are
Does anyone see anything that would break In the meantime, I’ll stick with P.S.: Pure ESM packages are somewhat painful, but I appreciate the migration pressure created by maintainers. The faster we move the ecosystem to ESM-only, the better for everyone. This year I had to explain differences between ESM and CommonJS to new devs and also assist with quite intricate repo configs. I hope all this knowledge becomes unnecessary for most folks by the end of 2022! |
The pressure you're discussing is not actually helping the ecosystem; i invite you to check the per-version download counts for every package that's gone ESM-only. It's a clear signal that developers do not want that. The reason is because sindre is actually authoring their packages incorrectly - by omitting Regardless of this plugin's inevitable eventual support for ESM resolution - which should of course work - I would strongly encourage you to migrate to package authors that maintain compatibility over ones that attempt to subjugate their users by forcing them to use a specific subset of node's available module systems. |
@ljharb The official docs for the field don't mention
On the other hand, the LOAD_AS_DIRECTORY(X)
1. If X/package.json is a file,
a. Parse X/package.json, and look for "main" field.
b. If "main" is a falsy value, GOTO 2.
c. let M = X + (json main field)
d. LOAD_AS_FILE(M)
e. LOAD_INDEX(M)
f. LOAD_INDEX(X) DEPRECATED
g. THROW "not found"
2. LOAD_INDEX(X)
|
@rasenplanscher That still makes "omit main entirely" an incorrect approach, unless there's no In that case, my testing shows that setting main to |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This workaround works for me: https://gist.github.com/danielweck/cd63af8e9a8b3492abacc312af9f28fd |
Could Or maybe this module could just use either |
@silverwind that would be trivial when "exports" is a string, but the formats node supports for it are varied and complex. I've tried |
What do you think about starting with support for string form |
That's certainly a viable option, although I'm still uncertain about it. Most packages should be using the object form so they can expose package.json also, otherwise their package won't work with a bunch of tooling. Notably the package from the OP doesn't have exports - https://unpkg.com/browse/react-gbajs@1.0.2/package.json and another mentioned above ( https://github.com/Rich-Harris/periscopic/blob/58d8184ddd3808db26340b6e8c7f6b3ef8811d9f/package.json#L8-L10 ) has an object form using |
Never heard of this. How would such a package.json export look? When a package declares a string |
and no, with a string |
You're right, if I try that for such a module, I get
I guess it could still be worked around via manual resolve to absolute path and |
Not reliably - because if the main is in a subfolder, that might have a package.json itself, it gets tricky. That's a big part of why it's a best practice for packages using |
Actually I point Anyway, thank you for your hard work! |
Yes, I do that as well. I just add a dummy |
For
Funny that |
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
Full code
./node_modules/.bin/eslint .
What did you expect to happen?
Should raise no error. This package is present in the
node_modules
.An important note:
Since it's only for the browser, it has the field
browser
instead ofmain
in itspackage.json
(link). I made it following the NPM documentation.Despite that, I noticed that by adding the field
main
in itspackage.json
, the error suppress - but it doesn't look correct.What actually happened? Please copy-paste the actual, raw output from ESLint.
Steps to reproduce this issue:
yarn
on its rootcd brush
yarn run lint
The text was updated successfully, but these errors were encountered: