Allow multiple .jscsrc files

[rubennorte]

It's pretty usual having nested jshint configurations for some directories like tests/spec, where some additional globals are defined and some rules can be changed (like the maximum line length). It'd be perfect if we could have that feature in jscs.

Example:

root/
  .jscs (some rules)
  spec
    .jscs ("extends": "../.jscs" + some changes)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rubennorte]

Having specific configurations for inner directories (without extend) would also be great. Now only the root .jscsrc applies.

[qfox]

You can make presets with jscs and use them as you want to use basic rules. Literally, it's the same.

But I'm not really sure that we should make internal configs without extending the basic one. The first time I've read your message I thought that you need config for inner directory without extending the root one.

Atm you can use --preset manually like: jscs -p root/.jscs -c root/spec/.jscs targets.js.

Probably you can solve your checking issues with making a simple preset, loading it somehow (via plugin or option), and then use it for all your target with different excludeFiles mask sets.

Is it ok for ya?

[rubennorte]

Maybe I didn't explain it very well.

I think the main problem here is that the configuration is not scoped to the file being checked but to the working directory where the process was run. That way if I put a .jscsrc file inside any other directory of my project it's being ignored because the main .jscsrc is used.

The configuration in JSHint works the way I say and it's really flexibile, allowing us to apply different configurations for different directories with no need to run the command multiple times per configuration or target. The possibility to extend other configuration files is just something added on top of that.

Do you understand what I mean?

[qfox]

with no need to run the command multiple times per configuration or target

That's what we need to talk about.

Do you understand what I mean?

Absolutely, I've just note that there is workaround.

@markelog @mikesherov What you think about it? I think it's pretty close to overloading .gitignore for subpaths at my point of view.

[markelog]

You can replace extends with preset you would get same picture when as soon as #109 is done and we would need to implement more elaborate config search.

[mikesherov]

These are solved problems in other linters, we don't need to reinvent the wheel. "Extends", finding up from the file rather than cwd, .jscsignore file, Config per file rather than per run, requireable plugins... are all standard behavior for a linter.

We should just roll up our sleeves and do the work rather than discuss merits and workarounds, IMO.

[mikesherov]

BTW, @markelog, I wasn't suggesting you were doing that. I was directing to the team in general.

[markelog]

i can take this one, sounds like post 1.12 though, for

we would need to implement more elaborate config search.

[elicwhite]

What's the status on this? It seems like there was some work done to enable loading from node_modules in this commit.

[wbyoung]

Just adding a 👍

For now, I've achieved what I want by adding a filter that does not report specific rules failing within a test directory, but this feels like a hack.

I'd love to see something more like JSHint extends with config the search starting at the file being linted and moving up through the directory ancestry.

[ryanbahniuk]

👍

[Krinkle]

Would love to see per-file (or per directory rather) discovery of the jscs config file, like JSHint does.

For the moment I rely on Grunt to exclude a subdirectory from one subtask, and register another with a different jscsrc file. E.g.:

scripts.test: 'jshint . && grunt jscs'

---
        jscs: {
            main: [ '*.js', 'src/' ],
            test: {
                options: {
                    config: 'test/.jscsrc.js',
                },
                files: {
                    src: 'test/'
                }
            }
        },

Where .jscsrc.js parses the parent one and overwrites a few properties.

[localnerve]

Just ran into this myself.
+1 for wanting to have jshint style directory configs.
When jsdoc is in the mix, you at least need a way to exclude or alter doc requirements from core requirements (consider mocha tests for example).

[sindresorhus]

I think JSCS should go with the ESLint approach of shareable config. A preset can then just be a published node module (optionally with the keyword jscs-config for discovery), npm linked module, or just a config file somewhere on the file-system.

I want to be able to just:

$ npm install --save-dev jscs-config-foo

{
  "extends": "foo"
}

And be done with it.

I noticed 7246452, but I couldn't find any docs for it.

I also honestly don't see the point of the built-in presets. Why can't they just be extendable configs on npm?

[elicwhite]

@sindresorhus We've been doing this for a while at the root of our apps:

{
  "plugins": ["wealthfront-javascript"],
  "preset": "wealthfront-javascript"
}

Wealthfront-javascript being this package on npm

We've still had to manually extend things inside our directory tree though

[markelog]

And be done with it.

Yeah, you could already do that starting from 2.0 - http://jscs.info/overview.html#preset -

Or you can load from it local path or as node module

Also see the examples, we received couple complaints about docs though, but i'm not sure how we could communicate this information in the better way, if anyone has any ideas, that would be cool to hear them.

This issue is only open so we could deal with multiple configs with the single jscs run. If someone would help, that would be awesome.

jscs-config for discovery

We do that, not with jscs-config prefix though, but with jscs- prefix, we could consider adding another one though. You could do that with filters, plugins, presets, reporters, etc. Any external entities in other words.

But that logic only for convenience, as i mentioned by the @TheSavior, you could publish your configs for a long time now. Although in @TheSavior case, he needs an additional rule distributed with npm-package, so he needs to use plugin interface. Although that rule is look like disallowIdentifierNames, but seems more powerful, i wouldn't mind including it to the jscs itself.

I also honestly don't see the point of the built-in presets. Why can't they just be extendable configs on npm?

Again, for convenience, a lot of people just want to do npm install jscs && jscs -p <preset> . and be done with it. Not sure why we should complicate that process.

So the main question is, how we could document it in the right way?

[sindresorhus]

From reading the docs you linked to, I still have no idea how to structure my node module, how to export the config, what keyword to use in package.json, etc. How do I make this a reusable preset?

This is IMHO how it should be documented: http://eslint.org/docs/developer-guide/shareable-configs Separate page. Clear instruction on how to structure the module and how to use it.

Can I make a preset that extends another one? I do that with ESLint.
Example: eslint-config-xo-space extends eslint-config-xo.

[markelog]

@sindresorhus found yet another unpleasant bug with loading external entities, which probably warrants 2.1.1 version.

How about i will make a pull to jscs-config-xo repo and based on that pull we will try to create extendable wiki page on how to use those presets?

[hzoo]

@sindresorhus Thanks for the report - I had some trouble as well with setting one up and had to do "preset": "./node_modules/jscs-preset-asdf/jscs.json". Looks like @zxqfox made https://github.com/jscs-dev/jscs-dev.github.io/issues/40 for this issue.

[sindresorhus]

How about i will make a pull to jscs-config-xo repo and based on that pull we will try to create extendable wiki page on how to use those presets?

Sounds good. Happy to review and improve docs when I learn how it works :)

jscs-config-xo should be renamed to jscs-xo, right?

[markelog]

jscs-config-xo should be renamed to jscs-xo, right?

Nuh, there is already couple projects that use jscs-config prefix, so i will add this one and jscs-preset too, just in case.

[sindresorhus]

@markelog Ok, I renamed it to jscs-xo regardless, as that's shorter and nicer.

[markelog]

Example is ready - sindresorhus/jscs-xo#1

[elicwhite]

Any update on this?

[Kienz]

Any news? Relative path still not working!

[markelog]

Relative path still not working!

This is why this is still open

[markelog]

At this point only major and CST related bugs will be fixed