Possible readme error for eslint-import-resolver-node

[msikma]

Hi there. I'm currently attempting to get this plugin working with (the equivalent of) a custom NODE_PATH. Was looking at the eslint-import-resolver-node documentation, which says to add an import/resolver key to the .eslintrc file, but after checking the code I see that it actually looks for import/resolve (in lib/core/resolve.js).

I'm not sure if I'm missing something, or if there's a discrepancy.

Relevant versions:

• eslint@1.8.0
• eslint-plugin-import@0.8.1
• eslint-import-resolver-node@0.1.0

[msikma]

Just to follow up, I was able to get it to work this way, using this .eslintrc with the following options:

"settings": {
  "import/resolve": {
    "paths": ["src/"]
  }
},

It seems that the contents of import/resolve is passed on directly to resolve, so it's not wrapped inside a node key like in the readme.

[benmosher]

Yeah, that is leftover from v0.10. I left the default behavior to minimize breakage to any config in the field.

Going forward, the same config can b provided as indicated in the resolver-node README--though I'll double-check it for accuracy. Whipped it together trying to get the Webpack resolver out this week.

On Nov 29, 2015, at 08:35, Michiel Sikma notifications@github.com wrote:

Just to follow up, I was able to get it to work this way, using this .eslintrc with the following options:

"settings": {
"import/resolve": {
"paths": ["src/"]
}
},
It seems that the contents of import/resolve is passed on directly to resolve, so it's not wrapped inside a node key like in the readme.

—
Reply to this email directly or view it on GitHub.

[benmosher]

Ah, sorry, the version number info didn't make it in the email. That is indeed the only way to configure paths before v0.11--I just shipped the resolvers with 0.11.

If you want to see the documentation for v0.8.1, you should be able to switch to the tag for that version. I believe that version of the README documents import/resolve, which does indeed pass straight through to the resolve.sync options.

[benmosher]

@msikma: I was just reading through your ESLint Gitter messages, and got a better understanding of what you were after.

Would it be simpler to have the Node resolver use NODE_PATH, if defined on process.env? Would be fairly straightforward.

I generally bake my NODE_PATH into build scripts as an export NODE_PATH=./whatever up top. Seems like it would follow that the resolver would pick this up and run with it, vs. having to configure it in again in .eslintrc.

[msikma]

Would it be simpler to have the Node resolver use NODE_PATH, if defined on process.env? Would be fairly straightforward.

Oh yeah, I think that would make sense, definitely. To my knowledge the only way to have your own import directory is to specify it using NODE_PATH (unless you're using Webpack or something else). There are some other hacks (such as a custom require() hook) but this is the proper way to do it I believe. So I think it'd be good to use it for the resolver as well. 👍

[alondahari]

Hi,
Not sure where you stand with this, but it's not working for me (getting a false negative on files relative to my NODE_PATH declared in the scripts).
I tried defining paths as described above, no luck either.
Had to disable the rule for now.
Am I doing something wrong?

[ShaunEgan]

I am having the same problem as @jazzdragon. Have tried both methods and still getting these missing require hits.

[ljharb]

NODE_PATH is deprecated and considered a bad practice; it should work while node supports it, but I'd recommend migrating away from it.

[alondahari]

What's a good alternative?

[ljharb]

All your requireable things should be in the local node_modules directory per the require.resolve algorithm, which is where dependencies go. There is no better alternative.

[ShaunEgan]

So I know this is probably getting off track of this thread, but regarding the deprecation. I did a bunch of reading and the recommended practices. They all seem to recommend keeping tests side by side with the files they test for.

So we usually keep our tests separate. We use the NODE_PATH to have the tests have the same require root path as our source. Without this, am I right in assuming that tests would have to have ../../ chains to make them work, or is there a better alternative.

The other approach I saw was that you can reference packages in package.json using the file: prefix. Using this, would it mean that every service with an application should be written this way? I don't have a problem with this, I just haven't seen it replicated anywhere.

Super interested in recommendations :)

[ljharb]

@ShaunEgan i highly disagree that colocating tests is a best practice; I think the opposite. However, when keeping tests separate, I simply use ../../ in my test files, yes - which is correct, because that's how node's require algorithm works.