*stickedOperators: remove documentation in preparation of deprecation.

[mikesherov]

No description provided.

[mikesherov]

@mdevils, @markelog now that I've added conditional expression spacing, there is literally no reason people should be using the *stickedOperators utilities. Here's the order of things that will happen.

1. immediately remove the documentation (hence this PR).
2. remove usage of the *stickedOperators in presets (PR coming soon).
3. add an error (line 1, column 1) for each file being linted with these rules telling them to use the other rules right before releasing 1.5.0
4. drop these rules completely right before releasing 2.0.0

[gustavohenke]

Nice.
I always had problems with these rules; the new conditional expression spacing seems way better.

[gavacho]

How does one specify that var x = a + b; is valid but var x = a+b; is not without using the *stickedOperators?

[mikesherov]

@gavacho, requireSpacesInBinaryExpressions.

[markelog]

@mikesherov

for each file being linted with these rules telling them to use the other rules

We probably should add those rules in the error message, or even not remove the documentation just yet, but add deprecation notice with explanation what rules to use instead, since this question comes up a lot.

[Krinkle]

@gavacho @mikesherov I can't find anything about requireSpacesInBinaryExpressions. I assume you meant requireSpaceBeforeBinaryOperators and requireSpaceAfterBinaryOperators. So the recommendation is people remove disallowRightStickedOperators in favour of those. I actually had both (not sure why) and it was causing issues for things like return +str or return +!!foo.

[mikesherov]

@Krinkle yes.

[Krinkle]

@mikesherov What about >, >=, <, and <=? It seems those don't work as expected when put in requireSpaceBeforeBinaryOperators and requireSpaceAfterBinaryOperators.

Filed #378.

[markelog]

We really should add all those binary operators to the test suite

[mikesherov]

@Krinkle yes, those are obviously bugs which should be filed as such.

[markelog]

Strictly speaking they are not bugs, since support for them weren't promised :-)

[mikesherov]

@markelog, you think at this point we're good to proceed with this?

[markelog]

I think so –

We probably should add those rules in the error message, or even not remove the documentation just yet, but add deprecation notice with explanation what rules to use instead, since this question comes up a lot.

Thoughts?

[mdevils]

I believe we should include deprecation notice in the output once for each deprecated rule if it exists in the user config.

[mikesherov]

Ok, so it seems like:

1. Output deprecation notice once for each deprecated rule pointing to the correct rules to replace them with.
2. No longer perform the actual validations from those rules.
3. Mark current rules as removed (rather than deprecated) in the docs, considering as of 1.5, their functionality is removed and they always throw errors.
4. With the release of next non-patch version after 1.5, remove the rules completely from the codebase and docs.

[mikesherov]

OK, I'm going to proceed as per my comment on Thursday.

[markelog]

@mikesherov sounds good to me

[mikesherov]

@markelog can you just take a quick look here and see if it makes sense. Please ignore the duplication. I didn't want to sink time into DRYing code that will be removed shortly.

[mdevils]

I believe we should throw a warning in StringChecker once for the whole run.

[mikesherov]

@mdevils we are then left with the same issue as #334

The problem here is that throwing an error makes sense for CLI tools like grunt and gulp, but for plugins, not as much. For example, the Sublime Text Plugin via SublimeLinter will silently fail if an error is thrown. Same goes for a lot of the other IDE's.

Unfortunately, while this should be the plugins responsibility to fix, it's just as easy for us have this be a normal linting error and be gauranteed to not break the world.

[markelog]

It looks like it does not matter how we go on about it, result still will be unsatisfactory :-(. We need to figure out some way for 2.0 to make a nice output for these kind of messages, given that we probably will have a lot of them.

1. We could make `configure` method of those rules to output these messages in the console, but that would be an ugly side-effect
2. We could leave those sticked rules in, but beside they usual message we could output these deprecation messages
3. We could throw, but output is ugly and plugins would silently break
4. Or output deprecation message only for first lint file

Of these options, i like the second one (although i don't really like it), i know we should be noisy about this, but removing them is too radical for my taste.

[mdevils]

I'm agree with @mikesherov.

Let's not break compatibility with reporters and output an error for every file.

[markelog]

I didn't purposed to break anything, for me, this scenario is preferable –

We could leave those sticked rules in, but beside they usual message we could output these deprecation messages

But in any case, it's good to move forward.

@mikesherov could you release the new version? It would requires you to create jscs-browser.js file, changelog, tag, etc; - see the scripts commands in package.json. If you do, please don't forget to remove warning in the readme doc before publishing.

[mikesherov]

Ok. Will do. Tomorrow is Father's Day in the US, so I may not have time. If not, I'll release Monday morning. Thanks everyone for coming to a resolution on this!