Thanks for pointing me to that issue, Nicholas. It does indeed look like it will solve my problem. I've subscribed to it and will check it out when it's complete.
On Wednesday, January 25, 2017 at 3:53:18 PM UTC-5, Nicholas Zakas wrote: > > Inline comments are intentionally a lot simpler, and the linter itself > does not have access to the file system. > > We are working on a way of overriding configs based on glob patterns: > https://github.com/eslint/eslint/issues/3611 > > I think that would also solve your problem. > On Tue, Jan 24, 2017 at 10:09 PM <[email protected] <javascript:>> > wrote: > >> I was wondering if it would be *generally* useful to allow specification >> of an external configuration via an inline comment? For example, if the >> following comment was present in a source file: >> >> /* eslint-config path/to/my-config */ >> >> it would be equivalent to specifying said external configuration via the >> CLI's --config option. >> >> Here's the use case where I found myself thinking I needed such a >> feature... Consider the following contrived project layout: >> >> my-project >> ├── client >> │ ├── .eslintrc.json >> │ └── client.js >> ├── server >> │ ├── .eslintrc.json >> │ └── server.js >> ├── .eslintrc.json >> ├── .eslintrc-gulpfile.json >> └── gulpfile.js >> >> I want *client.js* and *server.js* to use the configuration in their >> sibling *.eslintrc.json*, which inherit the configuration in the parent >> *.eslintrc.json*. However, I want *gulpfile.js* to use the >> configuration in *.eslintrc-gulpfile.json*. This isn't a problem during >> my build process because I can run two separate ESLint tasks: one for >> *client.js* and *server.js* that uses the default configuration >> hierarchy and one for *gulpfile.js* where I explicitly specify the >> configuration via --config. >> >> I run into a problem when using the Atom linter-eslint plugin. That >> plugin relies on running ESLint without an explicit configuration, thus the >> configuration hierarchy is employed. In my case, this results in using the >> *.eslintrc.json* configuration sibling to *gulpfile.js*, which then >> produces many false positives/negatives within Atom. So my theory is that >> by adding a feature like the eslint-config comment described above, the >> Atom linter-eslint plugin will Just Work because the ESLint engine will >> correctly pick up the desired external configuration. >> >> There's obviously a bunch of unanswered questions as to the behavior of >> the eslint-config comment in the presence of other configuration >> comments, but I was just curious if even the thought of specifying an >> external configuration via an inline comment is just a Bad Idea. (I'm open >> to any other alternatives for getting the Atom linter-eslint plugin to work >> as desired. The most obvious suggestion would be to simply inline the >> entire configuration within *gulpfile.js*, but the >> *.eslintrc-gulpfile.json* configuration in my case extends other >> configurations, and thus we've come full circle as there does not appear to >> be a way to extend a shareable configuration via an inline comment.) >> >> Thanks, >> Steve >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ESLint" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "ESLint" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
