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
Support block-comment version of eslint-disable-line #8781
Support block-comment version of eslint-disable-line #8781
Comments
Would it make sense to also make |
Yeah, absolutely. Waiting for accept then ;-) |
Oops. Am I right that this issue already has 3 ok's? |
Previous discussions on this have been "resolved" with the notion that we shouldn't have two ways to do the same thing. I would add that if we support line/block comments for some of our configuration comments, then users will be confused why we don't do so for all configuration comments. Are we sure we want/need to do this? |
@zxqfox Need one more 👍 to get this accepted. Since you proposed it, you count as champion. We need champion + 3 +1s |
This is a core change, so it would need to be approved by the TSC. |
Oh, right, sorry about that. For some reason I was thinking that this would be a rule change. |
I'd like to just throw out there that I think that both line and block comments should be allowed for all configuration comments, in regards to @platinumazure's comment. I remember being confused why I had to have specific types for certain configuration options, and in the case of JSX, requiring line comments are very limiting and make for messy code, which is why we have this issue. That's my vote. |
How does it behave in this case? /* eslint-disable-line
*/ alert(1); |
@mysticatea Looks like it should disable both lines or does not work at all and throw an error or warning (the second is better for me). @platinumazure There are cases in wild that can't be achieved with line-form. Also JSCS supported block-form of line-disabling directive. Actually, that's my case. |
I'm not sure about this. I don't think we need to support the use case described in #8779 (using a block comment rather than a line comment to make sure line numbers in the file are preserved). Automatically inserting I do think it would be nice to find a solution for the JSX case (#7030). But |
Guys guys, if we said we support JSCS — there is nothing to discuss, JSCS supported this and ESLint should support this too. The main point we can't migrate from JSCS because of this and there are no workaround. |
We promised compatibility with JSCS, not uniformity. We don't have
identical rules and options and sometimes have a different contract to do
the same thing in JSCS. I don't see commenting of lines with block comments
as core JSCS or ESLint functionality so I don't think we have to provide an
identical mechanism.
I would love to see if we can solve the use case some other way.
…On Jun 28, 2017 7:19 PM, "Alexej Yaroshevich" ***@***.***> wrote:
Guys guys, if we said we support JSCS — there is nothing to discuss, JSCS
supported this and ESLint should support this too.
If no — then no. But then why we deprecated JSCS and closed? We should
reopen it as a fork of ESLint or something like that.
The main point we can't migrate from JSCS because of this and there are no
workaround.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8781 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AARWeq3TjnLRRE249WXUF8_qGy9veDVzks5sIu2pgaJpZM4OBw47>
.
|
Well, what should I do with my case? I literally can't do the same with ESLint. It means there are no compatibility. |
Again: I would love to see if we can solve this some other way. This is feeling like an XY problem. I don't know what actual problem you're trying to solve, but this feels like a clunky way to do it. I'm hoping we can come up with something better. |
Okay, sorry. I'll pray 🙏 |
@platinumazure Mind explaining what it is that you don't like about this solution? It's clear that you're not satisfied with this solution, but I don't know what about it you're against. My 2c: The multiline comment is an interesting case. Seems like it should treat lines that contain the beginning or end line of the comment as "the line" in question. I agree that a line comment would probably be clearer most of the time, but this feels like a case where we can decide on behavior, document it, and trust our users rather than limit them. And for what it's worth, this seems like a pretty reasonable style for a
|
Can you explain why the current directives don't work for you? |
I'm also not entirely clear on this. Yes, you'd have to move the |
It looks like the discussion here is still ongoing. Should we still discuss it at the TSC meeting, or should we remove it from the agenda until we have a concrete proposal or we're unable to reach consensus? |
I have a couple of files that should be prepared before prepublishing and I can't use myfunc(`a
b
c
d`);
// →
(something && myfunc(`a
b
c
d`)); Also we can't use Again, it worked well with jscs and even jshint. |
Tell us about your environment
What parser (default, Babel-ESLint, etc.) are you using?
default
Please show your full configuration:
What did you do? Please include the actual source code causing the issue.
What did you expect to happen?
It should work like in JSCS:
What actually happened? Please include the actual, raw output from ESLint.
Error reported.
The text was updated successfully, but these errors were encountered: