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
Glob override configs do not support "extends" #8813
Comments
FWIW that was the intended behavior and is even documented. I think the reason behind this was to prevent nested overrides because shared configs could also specify glob overrides. |
Also see #8081 (comment)
That's a good point -- we should figure out how we would handle this. Should we just ignore nested overrides? Nested overrides are a fatal error within a single config, but it might be annoying to have that be the case with an extended config too (since that would make it difficult to reuse a config as a shareable config). |
I haven't tested this yet, but maybe someone else knows: what's the current behaviour for overrides in a shareable config? Normally the patterns are resolved to the location of the config file. Not sure what happens if you extend a config with overrides -- would they be resolved relative to the location of the extended config, or the config doing the extending? I wonder whether overrides should just be omitted from extended configs by default. |
I think it could also be quite handy to have glob overrides in shareable configs. You could for example create a shareable config which provides patterns for an opinionated project structure. |
At the moment I think they're resolved from the location of the config file in |
I think to understand how globs should work for glob overrides, it helps to distinguish between a direct config file and other config files. For this comment, a direct config file is a config file directly encountered by ESLint (either via ancestor directory traversal, I think glob patterns should always be applied relative to the direct config file. Between that implementation approach and some common sense on the part of configuration developers, things should "just work" in a sensible way. Example (one config)Suppose there is a config file in a project: Then file
Note that all globs are applied from the location of Example (multiple configs in project)Suppose there are two configs in a project: Then file
Opinionated folder structure configs?My approach would allow for opinionated folder structure configs per this comment, as long as projects know to extend from the shareable config or plugin-exported config at their root directory. For example, a configuration for Sails.js could assume a particular directory structure and add linting rules for certain directories. AmbiguityThe only ambiguity I can think of is using Drawbacks?It could get confusing if the same shareable config or plugin-exported config is extended from config files in multiple directories in a project and the config in question uses any globs more specific than Am I missing anything? |
I agree that it would be most useful if overrides resolved relative to the direct config file. I think we're talking about a few very similar questions in this thread and I want to make sure that they're all called out explicitly:
For question 3, I think the ideal case is to allow nested overrides blocks, and resolve all the globs (including ones from shareable configs) from the location of the direct config file (as described by @platinumazure). So, for example, if Not sure about the performance implications of allowing nested overrides, though... |
Here's a use-case that I hope is somewhat straightforward on should be common enough. I have my own shareable config that I use across projects. A common setup for me is to add the only project-specific things to "eslintConfig": {
"extends": "kokarn/react",
"parserOptions": {
"ecmaFeatures": {
"experimentalObjectRestSpread": true
}
},
"rules": {
"no-console": [
"off"
]
}
} For me an override that let's me add other files from my project, in this case a node server and stuff like that, would be awesome. "overrides": [
{
"files": [ "*.js" ],
"extends": "kokarn/nodejs"
}
] However, that would mean that those files shouldn't get the base ruleset from If this would be possible, it would be amazingly useful. |
If you simply want to apply a shareable config to certain files, you can do something like this: // .eslintrc.js
module.exports = {
...
overrides: [
Object.assign(
{
files: ['**/__tests__/*-test.js', '**/__mocks__/*.js'],
},
require('eslint-config-example/jest')
),
],
}; |
This only works in the case of .eslintrc.js and seems pretty hacky, even
tho it's pretty cool.
…On Sat, Aug 5, 2017, 17:06 Ayan Yenbekbay ***@***.***> wrote:
If you simply want to apply a shareable config to certain files, you can
just do something like this:
// .eslintrc.jsmodule.exports = {...
overrides: [
Object.assign(
{
files: ['**/__tests__/*-test.js', '**/__mocks__/*.js'],
},
require('eslint-config-example/jest')
),
],
};
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8813 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABT29JoeCdRYaMA8pnW_u7QTwplmvAlAks5sVITZgaJpZM4OFjqx>
.
|
i hate asking without having time to help move this forward, but i'm curious about the status of this. i'm really excited to use glob configs so that i can start co-locating test files with source files, but since i use a sharable config, the lack of is this being actively worked on? while i won't be much help contributing an implementation right now, i'd be more than happy to provide specifics about my use cases, if that is helpful. |
Not being worked on as far as I know. I may be able to have another look at this in about a month when I have some free time, but definitely don't depend on it. |
Adding this to the TSC agenda so we can officially accept the proposal. I want to make sure the proposal is stable before people start implementing it, so that we don't have to throw out peoples' work if the proposal changes after more discussion. TSC Summary: This issue proposes adding support for using |
This was brought up in today's TSC meeting, but we decided to postpone the discussion until the next meeting to give people more of a chance to read through the proposal. |
@not-an-aardvark thank you for the updates and for helping to get this moving forward a bit more officially. seeing the notes from the meeting, i thought i could provide a lit bit of detail of the approach i've had in mind in hopes that it could be helpful. as was highlighted in the notes, i see supporting my initial goal is to be able to co-locate tests ( while supporting i imagine this is a scenario your team has already considered, but hopefully a somewhat concrete example helps the team consider the value of each piece a bit more clearly. not being familiar with your meeting schedule, it looks like there are typically meetings 1 to 2 meetings per month. could you point me to details about when the next meeting might be? |
Thanks for the info!
There are meetings scheduled every two weeks, so the next meeting will be August 31st. |
In today's meeting, the TSC definitely wanted to support |
Also @travi thank you for the detailed comment - it really helped us clarify what we were discussing and what we want to do! |
thank you for the update. i'm glad my comment was helpful. as i mentioned, i do think both would be valuable, but the part that has been accepted is certainly the biggest value to start with. glad to see this continue forward. |
For the newer configurers among us, it should be noted that you'll also need to use the |
@chrisgarber Isn't
|
I couldn't get that to work. As far as I can tell
So I think if you are calling from the command line like |
That is correct. The `files` option only limits which files to match
against those coming in from the command line, it doesn't change that
result set. You still need to use `--ext` for anything other than `.js`
files.
…On Wed, Mar 13, 2019 at 7:11 PM chrisgarber ***@***.***> wrote:
I couldn't get that to work. As far as I can tell files can only *further*
limit the set of files on which eslint is working. Description of ext flag from
the docs <https://eslint.org/docs/user-guide/command-line-interface#--ext>
This option allows you to specify which file extensions ESLint will use
when searching for JavaScript files in the directories you specify. By
default, it uses .js as the only file extension.
Note: --ext is only used when the arguments are directories. If you use
glob patterns or file names, then --ext is ignored. For example, eslint
lib/* --ext .js will match all files within the lib/ directory, regardless
of extension.
So I think if you are calling from the command line like eslint . then by
default eslint will only lint JS files; if you search for a glob, like
lib/** it will match all files in the lib directory, whatever their
extension. Since the closest thing to a default seems to be eslint . I
thought it might be worthy of a note.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#8813 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACWkosLG1OYIdizNwA4B6AXDScpwkFlks5vWa-0gaJpZM4OFjqx>
.
--
______________________________
Nicholas C. Zakas
@SlickNet
Author, Principles of Object-Oriented JavaScript <http://amzn.to/29Pmfrm>
Author, Understanding ECMAScript 6 <http://amzn.to/29K1mIy>
|
For what it's worth there is a proposal that the |
ESLint currently forbids using extends in the override block, ie ``` { "extends": ["plugin:@typescript-eslint/recommended"] } ``` so we just have to add them manually for now. See eslint/eslint#8813 .
ESLint currently forbids using extends in the override block, ie ``` { "extends": ["plugin:@typescript-eslint/recommended"] } ``` so we just have to add them manually for now. See eslint/eslint#8813 .
ESLint currently forbids using extends in the override block, ie ``` { "extends": ["plugin:@typescript-eslint/recommended"] } ``` so we just have to add them manually for now. See eslint/eslint#8813 .
ESLint currently forbids using extends in the override block, ie ``` { "extends": ["plugin:@typescript-eslint/recommended"] } ``` so we just have to add them manually for now. See eslint/eslint#8813 .
ESLint currently forbids using extends in the override block, ie ``` { "extends": ["plugin:@typescript-eslint/recommended"] } ``` so we just have to add them manually for now. See eslint/eslint#8813 .
ESLint currently forbids using extends in the override block, ie ``` { "extends": ["plugin:@typescript-eslint/recommended"] } ``` so we just have to add them manually for now. See eslint/eslint#8813 .
ESLint currently forbids using extends in the override block, ie ``` { "extends": ["plugin:@typescript-eslint/recommended"] } ``` so we just have to add them manually for now. See eslint/eslint#8813 .
Now eslint/eslint#8813 is fixed this leads to much less object merging
How Can I create an override for some files in my eslint-plugin so that user don't have to use override in his .eslintrc? |
@moulikcipherX Your plugin just needs to export a config which has the necessary overrides in it; then users can extend that config in their own config, without worrying about the details. If you have any more questions, feel free to stop by our Gitter chat. |
What version are you using?
4.1.1
What did you do?
Tried to use a glob override config with an "extends" property
What happened?
Received an error.
What did you expect to happen?
No error-- glob override config "extends" should be intelligently merged with the main config's "extends".
My suggested approach would be to prepend the override's extends array to the parent config's extends array and removing duplicate entries that occur later in the resulting array, but there might be a better way to do that.
The text was updated successfully, but these errors were encountered: