Changes to make for v1.0.0 [$35 awarded]

[btmills]

The following rules are deprecated and should be removed in v1.0.0:

• generator-star
• global-strict
• no-comma-dangle
• no-empty-class
• no-extra-strict
• no-space-before-semi
• no-wrap-func
• space-after-function-name
• space-before-function-parentheses
• space-in-brackets
• space-unary-word-ops
• spaced-line-comment

To remove a rule:

1. Update the deprecation notice in docs/rules/{rule-name}.md to indicate removal.
2. Delete lib/rules/{rule-name}.js.
3. Delete tests/lib/rules/{rule-name}.js.
4. Remove the rule's default setting in conf/eslint.json and any environments in conf/environments.js.
5. Move the rule's entry in docs/rules/README.md to the Removed section.

In addition, the following behaviors are deprecated and need to be changed for v1.0.0:

• The existing default behavior for strict with no mode option should be removed. The new default when the rule is enabled without any options should be "function". This change should be reflected in the rule's documentation.
• In lib/api.js, stop exporting cli.

The $35 bounty on this issue has been claimed at Bountysource.

[btmills]

This issue combines #1692, #1861, and #1889. @nzakas those three can be closed once you're satisfied everything from those is present here.

The existing default behavior for strict with no mode option should be removed and the default should be changed to one of "never", "global", or "function".

I'm in favor of "function" as the new default since it's most similar to the existing default. Thoughts?

[nzakas]

Yup, function by default and global in the node environment.

[btmills]

Yup, function by default and global in the node environment.

I've updated the issue description.

[ilyavolodin]

I would suggest not deleting documentation for rules, and instead marking them as no longer supported with a link to the new rule. Some people might stick with the older version of ESLint for a while.

[nzakas]

That's a good idea.

[btmills]

I like it. The gensite target in Makefile.js should still work with version added stamps since it's based on the documentation files. Might we want to do something similar for the version in which a rule was removed?

[lo1tuma]

I’ve added no-comma-dangle to the list of rules which should be removed with ESLint 1.0.

[btmills]

Added generator-star as per #1987 and space-before-function-parentheses as per #2050.

[nzakas]

👍

[btmills]

Based on #2180 (comment), will the --rulesdir option be removed in v1.0?

[btmills]

The Node.js API docs state:

the cli object has been deprecated in favor of CLIEngine. It will be removed at some point in the future.

Will this be removed as part of v1.0?

[nzakas]

I think we need to keep --rulesdir for now, probably remove in 2.0.0.

We should stop exporting cli for 1.0.0

[ilyavolodin]

no-empty-class should be removed in 1.0.0 as well. It's being replaced by no-empty-character-class

[btmills]

Updated to include no-empty-character-class.

[xjamundx]

@btmills no-empty-class should be removed, not no-empty-character-class :)

[btmills]

@xjamundx ...usually I can read. Fixed!

[gyandeeps]

@btmills Please add spaced-line-comment to the deprecate rule list. As per #1088

[btmills]

@gyandeeps Updated to include spaced-line-comment.

[IanVS]

Has anyone done work on this so far? It seems pretty straight-forward, if I'm not missing something. I'm happy to start working on it if the issue is ready and accepted.

[nzakas]

These are the last tasks after the other 1.0.0 ones are complete.

Agree it would be nice to document when rules were removed. We will need to keep the docs for those rules up for a while to help those who are using older versions.

[ilyavolodin]

One more task, just noticed in documentation for strict rule there's a paragraph that is saying that "default" option will be deprecated in 1.0.0. Here's the link: http://eslint.org/docs/rules/strict#deprecated-mode-default

[btmills]

@ilyavolodin I added that link to the strict task.

These are the last tasks after the other 1.0.0 ones are complete.

@nzakas So that I can prioritize, what order are you planning for the 1.0 tasks?

[nzakas]

This issue is last as it's the most destructive. We also need the warning system fit missing rules to be complete before we do this.

Otherwise, everything is roughly equal in priority.

[IanVS]

I don't see any issues with a v1.0.0 milestone for a missing rule warning system. (Nor any issue at all for it, but I haven't sifted through all 100+).

It sounds like this should be the last task that is merged. Does that mean it is also the last which should be worked on? I would love to contribute to v1.0.0 in some way, and this seems like a task I could handle and start creating a PR for.

[gyandeeps]

@IanVS I think this is what you are looking for #1549

[nzakas]

@IanVS Yes, this would be the last merged as it's the most destructive. It does also rely on #1549 as a way to mark rules as removed.

@gyandeeps are you still working on #1549 and #2736? Either of those might be good for @IanVS to take a look at.

[gyandeeps]

@IanVS Feel free to pick anyone.

[nzakas]

@IanVS do you want to look at #2736?

[IanVS]

@nzakas Sure, should have a PR ready shortly.

[IanVS]

It seems that coverage reports in coverage/lcov-report/lib/rules/ are not cleaned out when a rule is removed and tests are rerun. Is that possible?

Edit: I just noticed that coverage/ is in .gitignore so it doesn't matter.

[IanVS]

I have a PR ready to go as soon as this is accepted.

[nzakas]

Ready!