.jscsignore

[jscs-dev]

.jscsignore

[mdevils]

Please, explain this issue.

[qfox]

Possibility to create separate file with ignored files and paths to put all of them to .jscsignore.
I think it's the same as excludeFiles

[qfox]

@mdevils sorry. Maybe I'm wrong and there is no reason to split it to a separate file. But at the moment we can't provide some additional options, or decline some of commons, for concrete inner directory.

For example, in my cwd I have .jscs.json n.1, but some path in the tree shouldn't be checked because of some reasons. I'm putting there .jscs.json n.2 and nothing happens. ;-)
But it's another issue.

[mdevils]

Have you seen excludeFiles option?

[mdevils]

Can't get why excludeFiles is not enough.

[qfox]

@mdevils I want to put ignores to inner directory.

/
  .jscs.json
  vendor/
    .jscsignore
    something-dirty.js
  ...

[ShimShamSam]

I'm not sure why this was closed. Not only does it solve the use-case presented by @zxqfox, but it is also more in line with other files like .gitignore and .jshintignore

[mikesherov]

@zxqfox, the original poster, closed it after seeing that excludeFiles matched his use case.

[qfox]

;-D yep. I couldn't find a reason to make additional file excluding mechanisms.

@Knotix what's your case?

[qfox]

@mikesherov I'm thinking about using .jshintignore files. jscs requires valid js-code and usually executes after jshint. So... If some files doesn't checked by jshint because of .jshintignore, jscs will fail. What you think about it?

[ShimShamSam]

I really just prefer it for consistency. It would match Git's and JSHint's method of ignoring files.

[andrewdeandrade]

Turns out I have a use case for wanting .jscsignore files.

We're trying to write a node_module for our entire organization that encapsulates all our linting rules so every new projects can just npm install our linting module. This means that we are running jscs with the config option pointing to either a .jscsrc file in node_modules/ folder or calling it on a symlink from the project root to the universal .jscsrc file in the node_modules/ folder. This presents two problems:

(1) the excludeFiles array is calculated relative to the path where the .jscsrc file is located.
(2) no ability for a project owner to ignore files on a project by project basis.

FWIW this module makes it really easy to implement ignore files: https://www.npmjs.org/package/fstream-ignore

[selfcontained]

Just adding another voice to the mix in support of a .jsrcignore file, and restating what @malandrew mentions. One of the benefits from supporting an optional ignore file in addition to your config file, like jshint does, is that you can share the same style enforcements across projects, but allow for things like project specific ignore files to be handled in the project.

[indexzero]

Adding a +1 for a separate .jscsignore file for the same reason.

[mikesherov]

OK, I'm reopening this considering sufficient user demand and use case. /cc @mdevils @indexzero if you want to take a crack at it... by all means!

[qfox]

Any ideas how to load this file and merge with excludeFiles option?

[mikesherov]

I'm not really sure. In an ideal world, we'd deprecate excludeFiles in the config and remove in 2.0. Thoughts, @mdevils?

[qfox]

It looks like some excluding container (object) that can be copied and extended (or replaced) with inner (by fs tree) .jscsignore files, it also should load these files on walking, and it will be used instead of (or with) global excludedFiles.

It's also very close to inner configurations.

btw. Should we use .jshintignore files at the same time with .jscsignore? Just I think it's the same list just because code should be valid. But it can broke jsx and custom esprima parsers so we need to think about it. Maybe just an option in .jscsrc which files JSCS should use as ignore-files?

[yutin1987]

{excludedFiles: '.jshintignore'} is a good idea.

[mikesherov]

@zxqfox would you like to tackle this for 1.12?

[qfox]

@mikesherov yep. I'll do it ;-)

@mdevils Please take a look here, really want to know your thoughts.

[masi]

I think support for .jscsignore is fine, but even better would be if I can name a ignore file. Either in the config or as CLI parameter. Then I could do:

jshint --exclude-path=myjsignore
jscs --exclude-path=myjsignore

a simple myjsignore could look like this:

*_/min.js
*/minified.js
*/_packed.js

[qfox]

@masi Yup. But if you gonna use .jshintignore or .gitignore as .jscsignore you can get troubles with different formats.

Anyone against --excludes-file option name?

[mikesherov]

Yes, I'm against it for now. A symlink can be created at the os level to achieve the same goal without have to add another option to jscs.

[qfox]

@mikesherov I'm agree in common, but e.g. git on windows doesn't support symlinks.

[masi]

Different formats would indeed be troublesome. In my personal ideal world - :) - jshint and jscs are using the same format as git. But I'm fine with a shared format amongst the JS utilities.

[qfox]

@masi In ideal world — yes. I'm gonna use and suggest for jshint ignore package. Guys at jshint also going to a .gitignore format (jshint/jshint#1917 and jshint/jshint#1758 (comment)) so I think it's a right way.

Thoughts?

[mrjoelkemp]

What's the status on this? I'm tempted to close it as orphaned unless there's a strong objection.

[qfox]

Waiting for #1150 to finish this.
Also there is #1159 — I think we should change this logic in 2.0.

[mikesherov]

I still very much want this.

[mdevils]

I feel OK deprecating exludeFiles and implementing jshintignore/gitignore-compatible .jscsignore file.

[jwhitmarsh]

👍

[iamstarkov]

👍

[shawn-simon]

How is there no option to specify an ignore file...

[mikesherov]

@shawn-simon there is. It's called the excludeFiles option. This ticket is to move to a separate ignore file from the current mechanism.

[shawn-simon]

That's not a file, it's json. I would like to have all of the ignores in one place, since I'm using jshint as well. Also, for some reason excludeFiles is fired in relation to your current working directory, not the config file. At least it works though!

[markelog]

If anyone would help us with this ticket, it would be great

[jwhitmarsh]

I'd be interested in helping out with this.

[mrjoelkemp]

One idea for tackling this is to use the newline delimited contents of the jscsignore to populate the excludeFiles configuration array internally.

[mrjoelkemp]

@jwhitmarsh friendly ping. Any progress on this?

[ronkorving]

Would love this too!

[adamreisnz]

Was reading this and seeing how it was raised in 2013, really hoping that it would be in by now. Either a .jscsignore or to specify a path to the ignore file to use, so that .jshintignore can be recycled. Anyway, +1 from me for consistency with other libraries/tools. Might give it a crack myself later if I have some time.

[andrewdeandrade]

FWIW, I'm no longer +1 on this. I've completely switched over to eslint since it pretty much meets all the needs that jscs used to address.

[adamreisnz]

@malandrew Thanks for the info. I will look into it as well.

[indexzero]

@malandrew that passive aggressive behavior is not welcome here. @adambuczynski would love your contributions if you have time. The biggest win that jscs has over eslint is that the autofix support is much more robust right now.

At GoDaddy we use both eslint and jscs together. eslint strictly for linting and jscs strictly for style. It is a very nice separation that I would recommend adopting.

I am still very much +1 on this as it bit me recently.

[indexzero]

I put a $200 bounty on this issue. Lets do this folks!

[adamreisnz]

I used to think that it's a good thing to have them separate, but I'm not sure anymore. Especially since I find myself just merging the results of jshint and jscs in my gulp tasks anyway. I haven't yet tried the autofix feature, because I'm a bit paranoid about software making coding decisions for me, but if it's only style then perhaps I should give it a go.

[indexzero]

@adambuczynski exactly. I personally really only want autofix for style. Anything else does make me a little nervous.

[dsebastien]

+1

[nescalante]

+1, any updates on this one? seems to be backed on bountysource

[markelog]

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