Comments (20)
What about inserting this change in a 0.5.x version?
We could add a warning about it in 0.4.0, then in 0.5.0 the default value is changed to empty.
However I'm not sure if this is semantic versioning 😕
from grunt-jscs.
Agreed.
from grunt-jscs.
Looks like this was addressed in: 0f1ac1a
from grunt-jscs.
Not really, we plan to change it to null
in v0.5.0. I've left this issue open as a reminder when v0.5.0 gets released.
from grunt-jscs.
Great, thanks.
from grunt-jscs.
@gustavohenke is this going to get into this version you're about to release?
from grunt-jscs.
I'm now seeing the mention in jscs-dev/node-jscs#379 by @markelog, unfortunately I had ignored that issue :(
Well, thinking more about it, jscs assumes that no config defaults to .jscsrc, what we've being doing since the begining. What do you guys think about it?
from grunt-jscs.
I'm fine either way. It's up to @markelog
from grunt-jscs.
I've been thinking of adding a explicit warning instead of using null
as default value for v0.5.0, and then we postpone tha change again to v0.6.0.
@mikesherov @markelog opinions?
from grunt-jscs.
Well, I ended up opting for the original proposal.
from grunt-jscs.
BTW, v0.5.1 is out (0.5.0 lacked the readme changes... d'oh!)
from grunt-jscs.
I'm confused. I just tried to upgrade from 0.4.4 to 0.5.1 and it seems it no longer works as expected. I'm aware of this thread but it's sufficiently vague that I'm not certain whether this change was intended to work out this way.
I used to hardcode the path to .jshintrc
and jscs.json
. When jscs changes its standard to .jscsrc
I decided to follow suit and in addition no longer hardcode it. The auto-discovery works great, and matches the behaviour of standalone node-jscs, and is still quite stable because the package versions are fixed in package.json
(if the default changes again, I can update it if/when I'm ready).
Same for grunt-contrib-jshint. I used to specify the path to it (.jshintrc
) but didn't like having to override it for subdirectories and specifying true
there now allows the jshint package to use its discovery instead. And again, it matches behaviour of the standalone jshint cli.
However it seems grunt-jscs-checker is quite the opposite as I'm now required to explicitly specify the file?
Running the jscs task (as of v0.5.1) with only a list of files to check:
- src/
- test/
- .jscsrc
- Gruntfile.js
- package.json
jscs: {
dev: [
'*.js',
'{src,test}/**/*.js'
]
},
...this passed with v0.4.4, but fails by default under v0.5.1:
$ grunt jscs --verbose
(..)
Running tasks: jscs
Running "jscs" task
Running "jscs:dev" (jscs) task
Verifying property jscs.dev exists in config...OK
Files: Gruntfile.js, src/EventEmitter.js, src/core.js, src/util/jquery.js, test/unit/EventEmitter.test.js, test/unit/core.test.js, test/unit/util.test.js -> dev
Options: (none)
Fatal error: Nor config file nor inline options weren't found
from grunt-jscs.
I think we can accept true
to use default behaviour from jscs.
Would this work for you?
from grunt-jscs.
I'm confused too. I was under the impression that removing .jscsrc just meant we'd fall back to JSCS's default, which is .jscsrc.
from grunt-jscs.
Or maybe I got the message wrong.
By default, grunt-contrib-jshint doesn't use any configurations if jshintrc option/config options aren't defined.
So, the purpose of not having a default value would be to not use .jscsrc
unless it's defined in the jscs
target.
@mikesherov, @Krinkle and @markelog, what are your opinions about using true
, just like grunt-contrib-jshint
?
from grunt-jscs.
I'd say that's one way to expose the default logic (it seems right now there is no way to trigger it, no matter how, I think it should be exposed in some way). It depends on what we think makes for a better default.
I'd say it's more common and a best practice to have the options in a file (so that e.g. text editor plugins and other scripts can simply invoke node-jscs and let it be used). And not requiring to specify true
would also make it compatible previous versions of grunt-jscs-checker.
We might not even need to have a way to disable it completely. Though if there's use for it, we could use null
as a way to disable loading of any config file and use true
(which would be the default) to have node-jscs find one.
from grunt-jscs.
Well. Thinking better about it now, it makes more sense to have a default.
grunt-contrib-jshint doesn't have a default because jshint uses some configurations by default (like expr: false
, but jscs does no style checkings if a configuration is not defined.
Let's do this way then:
- Falsy values (but not
undefined
) will completely disable loading of any config file (not onlynull
); true
orundefined
will use the default.jscsrc
;- Any string value point to the config file name.
from grunt-jscs.
I think the last proposal here makes most sense.
Sorry for any confusion!
from grunt-jscs.
I'll work on this one soon.
Let me know if anyone wants to work on it.
from grunt-jscs.
Working on this issue.
from grunt-jscs.
Related Issues (20)
- requireVarDeclFirst error when comment in function expression HOT 4
- grunt failing on jscs with node v5.2.0, npm 3.3.12 HOT 8
- config property not defaulting to true if verbose property included HOT 3
- 0 files without code style errors.
- Cannot find module 'lodash/lang/isFunction' HOT 4
- Use of "force" option should not disable reporter HOT 5
- "Unsupported rule" errors in grunt-jscs v2.7.0 using jscs v2.9.0 HOT 3
- Disallow spaces before new line HOT 2
- When using custom reporter, the errors for all the files, except one, are missing HOT 1
- Q: Supply config with url to jscsrc HOT 4
- "disallowMultipleVarDecl": {"allExcept": ["require"]} is ignored by grunt-jscs HOT 1
- Update to JSCS 3.x HOT 1
- JS Allocation failed - process out of memory HOT 1
- Expected token type "Punctuator" but "Identifier" found when using deconstructing with defaultvalues HOT 4
- The 'lodash' dependency has a Prototype Pollution vulnerability HOT 1
- Fix security issues from dependencies HOT 1
- Update lodash to 4.17.19 HOT 1
- Update js-yaml to 3.13.1 HOT 1
- Convert from using jscs(depricated) in favor of ESLint HOT 2
- Archive Repository HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grunt-jscs.