Skip to content

Use eslint and ember-template-lint directly (no longer lint during builds/rebuilds by default)#9009

Merged
rwjblue merged 5 commits intoember-cli:masterfrom
dcyriller:rfc-121
Feb 24, 2020
Merged

Use eslint and ember-template-lint directly (no longer lint during builds/rebuilds by default)#9009
rwjblue merged 5 commits intoember-cli:masterfrom
dcyriller:rfc-121

Conversation

@dcyriller
Copy link
Copy Markdown
Contributor

This is another attempt at implementing https://github.com/emberjs/rfcs/blob/master/text/0121-remove-ember-cli-eslint.md . It would superseed #8219 if you agree @kellyselden .

I am ready to write documentation for this. I'm not sure where though.

Drawbacks

This implementation has two drawbacks listed in the RFC:

  • no console warnings during builds
  • lint failures are no longer included in browser tests

For users wishing these features back, the way to go would be to manually install ember-cli-template-lint and ember-cli-eslint.

Links

Related discussions: ember-template-lint/ember-cli-template-lint#557, #8982 and many others 😄
RFC: https://github.com/emberjs/rfcs/blob/master/text/0121-remove-ember-cli-eslint.md
a WIP PR for this RFC: #8219

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 10, 2020

In general, this is looking good. The main thing remaining is to ensure that npm test / yarn test still fail (properly) if there are linting failures.

@Turbo87
Copy link
Copy Markdown
Member

Turbo87 commented Feb 12, 2020

The main thing remaining is to ensure that npm test / yarn test still fail (properly) if there are linting failures.

FWIW I don't think this needs to be a high priority. I usually use yarn test to run the tests and yarn lint to run all the linting checks and CI just runs both commands instead of relying on yarn test running both.

our CI template currently does run both, yarn lint and yarn test, so making yarn test do linting too, would mean that linting is now running twice 🤔

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 13, 2020

Rebased and fixed conflicts with other changes on master.

@kellyselden
Copy link
Copy Markdown
Member

@rwjblue It looks like you lost eslint in the rebase.

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 14, 2020

Thank you @kellyselden! Fixed.

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 14, 2020

CI is failing here because ember-template-lint@2.0.0 isn’t released yet.

@dcyriller
Copy link
Copy Markdown
Contributor Author

Indeed, sorry @rwjblue. I was on vacations. I rolled back to ember-template-lint v1 as v2 is still in beta. In theory, we should be able to upgrade template-lint to v2 by reverting 7d600b1.

As v2 is in beta at the moment
ESLint is not run anymore by the command `ember test` in a brand new app
(or addon). Indeed, ember-cli-eslint is gone now.
@dcyriller
Copy link
Copy Markdown
Contributor Author

dcyriller commented Feb 17, 2020

Rebased and fix the last CI failure in tests/acceptance/smoke-test-slow.js (that file was changed on master).

@mehulkar
Copy link
Copy Markdown
Contributor

The main thing remaining is to ensure that npm test / yarn test still fail (properly) if there are linting failures.

FYI, if the blueprint scripts don't include run the linter on npm test, new users will have no feedback on failures. Especially for the simple a11y lints, I think it's valuable to have those to nudge people in the right direction. Seems like a simple && change in the test script would fix this?

@kellyselden
Copy link
Copy Markdown
Member

My PR is a more complete version of this if you think I should revive/rebase it? #8219

@dcyriller
Copy link
Copy Markdown
Contributor Author

dcyriller commented Feb 18, 2020

if the blueprint scripts don't include run the linter on npm test, new users will have no feedback on failures.

I might be biaised on this. But to me, linting and testing look better run in parallel than sequentially. IMHO new users should be taught to run them in parallel in CI.

Also, we could document editor integrations (and also git hooks) to help users catch lint errors / warnings early.

@mehulkar
Copy link
Copy Markdown
Contributor

mehulkar commented Feb 18, 2020 via email

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 23, 2020

As part of merging RFC#121 we collectively agreed that the normal Node ecosystem conventions should apply. This means that we must ensure that npm test (or yarn test) fails when we consider the repository to be in a "bad state".

Prior to the changes proposed in the RFC, this was true (kinda? 😃) because ember-cli-eslint and ember-cli-template-lint would add errors to the ember test run. The pre-RFC121 setup fell down in a
few important (and IMHO fatal) ways:

  • It was only possible to lint files that were part of the application build. This meant that issues in files in other directories (e.g. index.js, ember-cli-build.js, etc) would not fail npm test / yarn test.
  • For addon's, important compatibility tests (ember-try scenarios) were never ran. If an addon didn't use the generated .travis.yml setup they would never have their compatibility tests ran 😱.

I've just pushed a commit that does a few specific things to address the concerns above, and make it possible to deliver on the promises that we made in order to land RFC121:

  • Add a lint script to projects that runs both lint:js and lint:hbs (in parallel) aggregating the results.
  • Add a test:ember script that runs ember test (previously was the test script).
  • Change the test script to run lint:js, lint:hbs, and test:ember scripts
  • For addons, rename the test:each script to test:ember-try (test:each seemed too ambiguous) and ensure test script runs this as well.
  • Simplify the .travis.yml configuration now that npm test actually does the right thing 😸

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 23, 2020

if the blueprint scripts don't include run the linter on npm test, new users will have no feedback on failures.

@mehulkar is absolutely right here! This is both fatal (for the change) and failing to account for this constraint would be intentionally choosing to deviate from the agreements we made in landing the RFC (see the detailed design).

My PR is a more complete version of this if you think I should revive/rebase it? #8219

@kellyselden - Your PR does indeed do much more than this one, but this one meets the requirements of the original RFC and sets the stage for us to actually have the conversations on the more controversial parts of your PR. I'd rather move forward with smaller changes here, then do follow up PR's to continue iterate...

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 23, 2020

our CI template currently does run both, yarn lint and yarn test, so making yarn test do linting too, would mean that linting is now running twice 🤔

@Turbo87 - Only if we screw up and forget to update both places 😜

},
"scripts": {
"build": "ember build --environment=production",
"lint": "npm-run-all --aggregate-output --continue-on-error --parallel lint:*",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checkout the docs on the npm-run-all command, but this is basically running lint:js and lint:hbs in parallel and ensuring the console output is aggregated (so they don't get interleaved).

"eslint-plugin-ember": "^7.7.2",
"eslint-plugin-node": "^11.0.0",
"loader.js": "^4.7.0",
"npm-run-all": "^4.1.5",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make it easier for others to find, npm-run-all is a very popular (~ 4M downloads/month) package made to do exactly the thing we are trying to do (with some neat features like glob support).

https://www.npmjs.com/package/npm-run-all

@kategengler
Copy link
Copy Markdown
Member

👍 I wonder if test:ember-try is also ambiguous? My thought is something like test:ember-compatibility?

Copy link
Copy Markdown
Member

@Turbo87 Turbo87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as I mentioned before, I personally would prefer to only run ember test for the test script 🤷‍♂

"test:all": "ember try:each"
"test": "npm-run-all lint:* test:*",
"test:ember": "ember test",
"test:ember-try": "ember try:each"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that means yarn test will now run ember try too? we explicitly changed it a while ago to not do that because running it takes forever and canceling it leaves your repo in a somewhat weird state.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should fix the cancellation issues (regardless of choice here), but IMHO this is a feature not a bug. All too many times I’ve been bitten by addons that are not using the default .travis.yml setup (using something like circle, GH actions, or other node aware tooling) that assume npm test means “good to go”.

@rwjblue
Copy link
Copy Markdown
Member

rwjblue commented Feb 23, 2020

👍 I wonder if test:ember-try is also ambiguous? My thought is something like test:ember-compatibility?

Done!

"test:all": "ember try:each"
"test": "npm-run-all lint:* test:*",
"test:ember": "ember test",
"test:ember-compatibility": "ember try:each"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test:ember-compat to make it easier to type?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know that folks will type it much? I'd prefer to avoid the abbreviation

@dcyriller
Copy link
Copy Markdown
Contributor Author

I've just pushed a commit that does a few specific things to address the concerns above, and make it possible to deliver on the promises that we made in order to land RFC121

Thank you @rwjblue!

As part of merging RFC#121 we collectively agreed that the normal Node
ecosystem conventions should apply. This means that we **must** ensure
that `npm test` (or `yarn test`) fails when we consider the repository
to be in a "bad state".

Prior to the changes proposed in the RFC, this was true (mostly
:smiley: ) because ember-cli-eslint and ember-cli-template-lint would
add errors to the `ember test` run. The pre-RFC121 setup fell down in a
few (IMHO important and fatal) ways:

* It was only possible to lint files that were part of the application
  build. This meant that issues in files in other directories (e.g.
  `index.js`, `ember-cli-build.js`, etc) would *not* fail `npm test` /
  `yarn test`.
* For addon's, important compatibility tests (ember-try scenarios) were
  never ran. If an addon didn't use the generated `.travis.yml` setup
  they would _never_ have their compatibility tests ran :scream:.

This commit does a few specific things to address the concerns above,
and make it possible to deliver on the promises that we made in order to
land RFC121:

* Add a `lint` script to projects that runs both `lint:js` and
  `lint:hbs` (in parallel) aggregating the results.
* Add a `test:ember` script that runs `ember test` (previously was the
  test script).
* Change the `test` script to run `lint:js`, `lint:hbs`, and
  `test:ember` scripts
* For addons, rename the `test:each` script to `test:ember-compatibility`
  (`test:each` seemed too ambiguous) and ensure `test` script runs this
  as well.
* Simplify the `.travis.yml` configuration now that `npm test` actually
  does the right thing :smile_cat:
@rwjblue rwjblue changed the title RFC-121: Remove ember-cli-eslint and ember-cli-template-lint from app blueprints Use eslint and ember-template-lint directly (no longer lint during builds/rebuilds by default) Feb 24, 2020
@rwjblue rwjblue merged commit 1dd8f4b into ember-cli:master Feb 24, 2020
@dcyriller dcyriller deleted the rfc-121 branch February 24, 2020 14:47
chancancode added a commit to ember-learn/super-rentals-tutorial that referenced this pull request Feb 26, 2020
ember-cli/ember-cli#9009 changed the yarn
test script such that it is not directly calling `ember test`.
Since `--path` is an option we want to pass to `ember test`, we
should call it directly.
chancancode pushed a commit to ember-learn/super-rentals that referenced this pull request Feb 26, 2020
chancancode pushed a commit to ember-learn/super-rentals that referenced this pull request Feb 26, 2020
@BlueRaja
Copy link
Copy Markdown

BlueRaja commented Jun 18, 2020

lint failures are no longer included in browser tests

Yikes, this drawback should've been a blocker.

If the main concern was build time, couldn't you skip linting during the build, while still running lint in the browser tests??

Copy link
Copy Markdown
Member

rwjblue commented Jun 18, 2020

couldn't you skip linting during the build, while still running lint in the browser tests??

No. How do those tests end up in the browser? Because we lint them in the build, and copy the output into the dist/assets/test.js.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants