Fix custom cwd not being passed through to ESLint #189
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is necessary with useEslintrc: true to make sure we look for .eslintrc / eslintConfig in package.json in the right place
sonicdoe
added a commit
to ricardofbarros/linter-js-standard
that referenced
this pull request
Sep 19, 2018
Otherwise, ESLint runs from the root directory which results in slightly different behavior than running standard on the command line. For example, if the project directory is within a hidden directory (e.g. /home/jane/.secret/project), ESLint ignores all files. Fixes #222. We cannot use standard’s cwd option here because standard-engine does not pass the cwd through to ESLint. See standard/standard-engine#189.
|
I ran into a similar issue in ricardofbarros/linter-js-standard#222 where a user had their project folder inside a hidden folder (e.g. I’ve worked around this in ricardofbarros/linter-js-standard@5b05e68 by changing the directory using |
|
Bump |
|
Sorry you had to wait so long! checking this out |
Flet
approved these changes
Jan 17, 2019
|
I'd like to do a bit more validation tomorrow to see if this will be a breaking change before publishing. I don't think it will be, but want to be sure :) |
sonicdoe
added a commit
to ricardofbarros/linter-js-standard
that referenced
this pull request
Aug 3, 2019
In standard v13 (with ESLint v6), the current working directory is evaluated using `process.cwd()` when ESLint is initialized, see [`config-array-factory.js`][1]. Since we currently change the working directory _after_ standard is required, ESLint will fail to find modules because it’s trying to resolve them from the root directory (as can be seen by the require stack of `/__placeholder__.js`). Using standard’s `cwd` option resolves this issue. Previously, we couldn’t use this option because standard-engine did not pass it through to ESLint, see [`5b05e68`][2] and [standard/standard-engine#189][3]. To maintain compatibility with older standard versions, we still use `process.chdir()` as well. Fixes #231. [1]: https://github.com/eslint/eslint/blob/f5e0cc40795f175692acb05daaadb91e9e5ae5d3/lib/cli-engine/config-array-factory.js#L346 [2]: 5b05e68 [3]: standard/standard-engine#189
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
While adding standardx (and potentially other standard-engine based linters) support to https://github.com/standard/vscode-standardjs, I noticed that the extension wasn't using my custom eslintConfig (which defeats the purpose of adding standardx support).
After some debugging, I found out that the actual detected cwd was passed to standard-engine, but never went through to ESLint itself.
Here's a fix for this issue, and a fix for the test that got screwed up in the process.
This may be a breaking change.
Have a good day !