Use eslint and ember-template-lint directly (no longer lint during builds/rebuilds by default)#9009
Use eslint and ember-template-lint directly (no longer lint during builds/rebuilds by default)#9009rwjblue merged 5 commits intoember-cli:masterfrom dcyriller:rfc-121
eslint and ember-template-lint directly (no longer lint during builds/rebuilds by default)#9009Conversation
|
In general, this is looking good. The main thing remaining is to ensure that |
FWIW I don't think this needs to be a high priority. I usually use our CI template currently does run both, |
|
Rebased and fixed conflicts with other changes on master. |
|
@rwjblue It looks like you lost eslint in the rebase. |
|
Thank you @kellyselden! Fixed. |
|
CI is failing here because ember-template-lint@2.0.0 isn’t released yet. |
.. and ember-template-lint Implements RFC ember-cli/rfcs#121
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.
|
Rebased and fix the last CI failure in |
FYI, if the blueprint scripts don't include run the linter on |
|
My PR is a more complete version of this if you think I should revive/rebase it? #8219 |
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. |
|
Parallel is better. We use `concurrently` for this but that’s probably not
something to put in the blueprint
|
|
As part of merging RFC#121 we collectively agreed that the normal Node ecosystem conventions should apply. This means that we must ensure that Prior to the changes proposed in the RFC, this was true (kinda? 😃) because
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:
|
@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).
@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... |
@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:*", |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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).
|
👍 I wonder if |
Turbo87
left a comment
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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”.
Done! |
| "test:all": "ember try:each" | ||
| "test": "npm-run-all lint:* test:*", | ||
| "test:ember": "ember test", | ||
| "test:ember-compatibility": "ember try:each" |
There was a problem hiding this comment.
test:ember-compat to make it easier to type?
There was a problem hiding this comment.
I don't know that folks will type it much? I'd prefer to avoid the abbreviation
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:
eslint and ember-template-lint directly (no longer lint during builds/rebuilds by default)
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.
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. --- Commit: ember-learn/super-rentals-tutorial@64f1714 Script: https://github.com/ember-learn/super-rentals-tutorial/blob/64f17140a8ddb38627d481453427942fa6290371/.github/workflows/build.yml Logs: https://github.com/ember-learn/super-rentals-tutorial/commit/64f17140a8ddb38627d481453427942fa6290371/checks
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. --- Commit: ember-learn/super-rentals-tutorial@64f1714 Script: https://github.com/ember-learn/super-rentals-tutorial/blob/64f17140a8ddb38627d481453427942fa6290371/.github/workflows/build.yml Logs: https://github.com/ember-learn/super-rentals-tutorial/commit/64f17140a8ddb38627d481453427942fa6290371/checks
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?? |
No. How do those tests end up in the browser? Because we lint them in the build, and copy the output into the |
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:
For users wishing these features back, the way to go would be to manually install
ember-cli-template-lintandember-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