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
Different settings for different JS versions #159
Comments
I think |
No opinions on this? |
I can see wanting to use no-var and object-shorthand on ES6 codebases -- those seem useful. Personally, I don't think always using Not a fan of comma dangle. Currently, we actively disallow it. Enabling it would cause almost every single dependent to start failing -- can't do that. The question is how do get no-var and object-shorthand for people on ES6 codebases. Are these things always going to require options? |
I think this is a very good idea. Would it also make sense to enable specific features? I currently compile my javascript as below and would love to have babel src -s --optional es7.functionBind --out-dir lib
I'm on the fence about comma dangle but to be fair it does make it easier to move lines up and down. Often when I do that there will be a line in the middle without comma which makes for a syntax error. @feross What do you mean with this?
As long as we specify somehow that the code is ECMAScript 6 it shouldn't require any more options. There is no reason to use |
I disagree: declaring vars with I agree forcing comma dangle is not viable solution as it would break compatibility but allowing it for ES>3 would not create any issues and allow cleaner diffs. |
I really think that we should either enforce it or forbid it. Letting the user decide for themselves just creates more bike-sheding? |
Remember, you can always "fork" standard if you care a ton about a single rule. Add your own rule with {
"extends": ["standard", "standard-react"],
"rules": {
"comma-dangle": [2, "always"]
}
} |
Defaulting to I also agree with @julien-f that using |
Agreed.
Although I am usually a massive proponent for This is not so in JS, as the So, while it pains me to say it, I think
@yoshuawuyts maybe I'm just being short sighted, but can you elaborate on this?
@julien-f this is the one positive I can see. Immutability rules. But IMHO, it is almost always better to be enforced through libraries like immutable.js then it is at the scope level.
We should ask eslint if we we can add an option That way we can solve a multitude of issues simultaneously! (e.g #167) |
@dcousens I was leading a refactoring effort at a previous job where ~1k-2k LOC files weren't uncommon. At that point it was impossible to remember all variables available in scope, and accidentally redeclaring variables happened. Actually I'm curious what the reasons against pro const
con(st) const
Does that sound about right? Let me know if I missed anything. |
Looks right to me. |
Here's a concrete problem I have with 'use strict'
const http = require('http')
function fetchGoogle (cb) {
let options = {
hostname: 'www.google.com',
port: 80,
path: '/'
}
if (Math.random() > 0.5) options.headers = { DNT: 1 }
http.get(options, cb)
}
fetchGoogle(function (res) {
console.log('got ' + res.statusCode)
}) With
My problems with
|
@feross It's because the semantic of If, in Node, |
@julien-f I think that's a pretty weak guarantee and it's not worth forcing users to use it in every possible situation where it could conceivably be used. Rules have to be worth the pain they cause, and I'm not yet convinced this rule is worth it. |
I can understand your arguments against the semantic of |
This is very subjective and personal but I don't really like the look of function complicatedStuff () {
let i = 0
const len = a.length
let futureKey = 'next'
let lastKey
const firstKey = futureKey
// ...
} But what do you guys think about enforcing const ENCODING = 'utf-8'
const OP_WRITE = 0x00
const OP_READ = 0x10 |
@LinusU Since |
Yup, non-transitive const is pants on head retarded IMHO.
I think that seems fair. |
Btw, in the last version of These rules are nice because they don't affect non-ES6 code. We can continue to enable these types of rules with no issues :) |
@feross It's not weak guarantee, it just only guarantee the value (or reference in object case) can not be modified. In C++, you should also use two In JS, we could use Notice it's far more ugly in Java than JS (in Java To be honest, Anyway, it's impossible to change the bad names now, what we can do is educating the js programmers to familiar the usage of |
@hax Thank you very much for this extremely clear argument :) |
And FYI, airbnb already enable |
If we ever switch to ES6 only, reference standard/eslint-config-standard-react#7 might be worth including. |
One more thought that I didn't see mentioned yet: |
I would also like to see |
I reckon opinions on dangling commas are divided, and thus that the best resolution in such a case is to not break backwards compatibility. I propose we don't break codebases. In that spirit I also dislike the prefer-const rule as forcing ES6 onto people is a bad thing. And yeah let's also not add options to enable different modes of standard because not having options is kind of the point of standard hah. |
Oh I also don't like option b: loosening rules as it makes a codebase more inconsistent which like also goes against the point of having a linter. I think we shouldn't force everyone to suddenly use dangling commas |
It does not break any code and people can keep using standard 8 if they don't want to use this feature.
|
I would also propose to look at the reasons behind the decisions and not judge purely on opinions or consensus of opinions. For |
At the cost of beating the dead horse, I would also like to see I am not sure what woudl be the implications of making |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Hey, I believe this issue is still relevant 🙂 |
I would like to side against prefer |
@tyrsius It's probably pretty rare, maybe it would be preferable to simply opt-out ( |
@julien-f I already have a way to opt-out of that behavior: use |
Let's agree to disagree of the meaning of these signals: for me |
I agree with you on the meaning of those signals. Our disagreement seems to be that I want to consider potential futures, where as you only want to consider the current state of the code. |
👍 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
FYI, I've started using more and more ESLint instead of Standard exactly for this reason (being able to target a specific version of ES, like ES5). |
@julien-f which rules is it that you enable on top of standard? Maybe it's time to just include them 🤔 |
I've listed the main one in the first message ( |
Ah, right, sorry didn't look at the top comment 😄 Oh, how I would love to have comma-dangle 😄 I don't know how many times I've talked about starting I don't see a problem with adding Personally, I would like to see |
@julien-f put up a PR for |
Hmmm,
Hmm, I would like to do some more research and see how many of those are actually targeting older environments 🤔 💭 |
I think it would make sense for some settings to differ based on which JS version is targeted:
functions
optionOf course it would be the best if compatibility is kept (a JS3 code is compatible with JS3 up to JS6 config).
I don't know what would be the best way to implement that, maybe via an options in
package.json
:The text was updated successfully, but these errors were encountered: