`eslint-plugin-import` breaks `eslint` if no `package.json`-file is present

[neurolag]

If there is no package.json-file in the file to check (or any parent directory), the eslint-run fails due to this piece of code:
https://github.com/benmosher/eslint-plugin-import/blob/802ce7d49d912289d590f735bf9bd2d931064863/src/core/packagePath.js#L11-L12

Following error is reported:

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received null
Occurred while linting {filename}.js

[ljharb]

We should definitely have a better error message - but why would you ever be running eslint outside of a node project with a package.json? global installs and personal configs are deprecated.

[neurolag]

I had it running without a package.json for testing the validity of my default .eslintrc.js-settings.

In order to do so, I create temporary .js or .ts-files and pass the corresponding eslint-settings to test programmatically rather than through a .eslintrc-file.

I think this is pretty much an edge-case. My current solution is to create a package.json file in the same directory like the test-files.

[ljharb]

It's certainly a scenario that's incompatible with this plugin.

We should improve the error message here, though.

[g1thuser]

We should definitely have a better error message - but why would you ever be running eslint outside of a node project with a package.json? global installs and personal configs are deprecated.

I also don't have a package.json, just because I'm not deploying any node modules in my project and therefore I simply don't need a package.json. IMHO this should be considered as a bug as it worked before without a package.json.

[GiladShoham]

Hi,
I'm the maintainer of https://github.com/teambit/bit
Many of our users have workspaces without a package.json file (as bit resolve dependencies from another file).
This breaking eslint entirely is a real issue for us.
I wish to have a way to tell the plugin to only check by other strategies (like making sure the package exists in the node_modules) folder, but skip the package.json validation completely (then also not throw an error in that case).

[ljharb]

@GiladShoham I'm a bit unclear how any workspace workflow could function without package.json (in a JS project); lerna, yarn, npm, rush, etc all use package.json for their workspaces implementation; even bazel has one in the root by default for JS projects. Things inside node_modules always have package.json, as far as I'm aware, since node_modules is not for manual modification, and all the tools that modify it require a package.json to be in the package (to provide the "name", if nothing else)

[dapullar]

@ljharb I'm experiencing similar issues under bazel. Although the root of the project may contain a package.json, the environment where the linting takes place may not. Since everything is sandboxed in bazel the package.json would need to be explicitly added to each lint target. You can almost think of it as a docker container which only includes the files to be linted + eslint (binary & plugins) per defined unit.

I think the requirement of a package.json is fine but, the error message threw me for a loop, coupled with a long debugging session to realize the missing dependency.

[GiladShoham]

@ljharb Using bit, you don't have a package.json in your workspace (only with your final packages). but the lint environment is a workspace. which means you don't have a package.json.
Bit manages all the dependencies using a file called workspace.jsonc which supports many additional features for dependencies management.
Using bit install command, bit will calculate the final dependencies for your workspace, and programmatically use a package manager (like yarn / npm / pnpm) to install them.
So the best option is somehow to teach the plugin about bit's workspace.jsonc file or even better to bit's final calculated dependencies.
But as I guess this won't be easy / high priority on your side. at least an option to not check the package.json but only the node_modules folder will be really great.
Anyway, the error when there is no pacakge.json for sure should be more descriptive (regardless of bit)

[ljharb]

@GiladShoham the pattern you describe will break all tooling in the ecosystem that expects package.json to be present - in other words, you can only lint a node project, and it's not a node project unless there's a package.json.

The best option is to fix bit to follow node conventions instead of radically deviating from them.

Certainly the error message can be made more descriptive.

[g1thuser]

@ljharb sorry, but I completely disagree. The purpose of the package.json is to create a npm package to share a project. If you don't want to share your project, you don't need a npm package and therefore also no package.json.

Furthermore eslint is for linting any javascript code, not only javascript code which is part of a npm package. So why does this restriction exist for eslint-plugin-import? I'm using several other third party plugins and not one of them is making this restriction.

And this has also nothing to do with not following node conventions. There aren't any node conventions which force you to create a npm package. Your arguments are not convincing and I'm still having the opinion, that this behavior should be considered as a bug.

[dapullar]

I agree with @g1thuser on this. eslint (& it's plugins) should always be functional as a standalone binary & should be able to lint the given files without external dependencies. If an external dependency is introduced (eg. package.json) it should be overridable in some manner. A linter should not rely on a specific workspace to be able to function without opt-in/out strategies.

At the end of the day we are sorting imports* here, you will be hard-pressed to convince everyone that a sorting algo requires a node project structure.

* I know more than sorting is going on, just being a little facetious