-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
Initial port to new ESLint API #275
Conversation
I could separate out the addition of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking this task! @voxpelli
Left some comments so we can discuss and improve the code.
Also: You forgot to update README.md
about the changes.
package.json
Outdated
"check:dependency-check": "dependency-check *.js 'bin/**/*.js' 'lib/**/*.js' --no-dev", | ||
"check:installed-check": "installed-check", | ||
"check:standard": "standard", | ||
"check:tsc": "tsc", | ||
"check": "run-p check:*", | ||
"test-ci": "run-s test:*", | ||
"test:tape": "tape test/clone.js test/api.js", | ||
"test": "run-s check test:*" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea to separate linting, tests, TypeScript check etc. (even if it could be in a separate PR as you said) 👍
We probably don't need npm-run-all
dependency and test
, test-ci
and check
scripts.
In the GitHub Actions we can run check:standard
then check:tsc
etc.
It makes things clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree that it makes things clearer + that the run-p
runs things in parallel, which is faster, especially locally.
This way adding / removing / changing a command becomes very clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. 👍
We can keep run-p
, I didn't know it runs in parallel.
The only thing, I think we don't need, is to have test
and test-ci
, it is not clear for me why we have both.
We can rename test-ci
to test
and remove test
.
Locally, we can simply run npm run check
and after npm run test
or I don't mind to have a command to run both, but we can maybe name it differently than test
as it runs not only test
scripts but also check
scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best practice is that npm test
should run all of the tests of a node project.
On CI though we want to run automated tests and linting separately, as linting only needs to be run once whereas automated tests should run on a combination of platforms.
Hence why there's both test
and test-ci
. Since they are only two different versions of sequential runs, run-s
, there's not really any duplication there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This suggested change is not really a big deal, it's non blocking for merging, so if you rather having test
and test-ci
it's fine like that for now but I would still rather not having test-ci
.
Best practice is that
npm test
should run all of the tests of a node project.
Yes, completely agree, but tests are not checks (linting, etc.).
We could separate these things.
On CI though we want to run automated tests and linting separately, as linting only needs to be run once whereas automated tests should run on a combination of platforms.
True. 👍
As else it checks `tmp/standard/`, which doesn't pass
Tweaked and fixed things here, this should now be much more ready for merge 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job! 😊
Nearly ready for merging, there are still some comments to be addressed.
package.json
Outdated
"check:dependency-check": "dependency-check *.js 'bin/**/*.js' 'lib/**/*.js' --no-dev", | ||
"check:installed-check": "installed-check", | ||
"check:standard": "standard", | ||
"check:tsc": "tsc", | ||
"check": "run-p check:*", | ||
"test-ci": "run-s test:*", | ||
"test:tape": "tape test/clone.js test/api.js", | ||
"test": "run-s check test:*" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. 👍
We can keep run-p
, I didn't know it runs in parallel.
The only thing, I think we don't need, is to have test
and test-ci
, it is not clear for me why we have both.
We can rename test-ci
to test
and remove test
.
Locally, we can simply run npm run check
and after npm run test
or I don't mind to have a command to run both, but we can maybe name it differently than test
as it runs not only test
scripts but also check
scripts.
Updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚀
There are still some comments, but they are non blocking for merging.
As it is a big BREAKING CHANGE and a quite big PR, I would rather to have at least 2 reviews approval before merging.
The complicated thing will be to migrate all the engines to this new standard-engine
and also the VSCode extension vscode-standard
.
I'm wondering how can we offer a smooth upgrade as this new version (v15) of standard-engine
introduce lot of BREAKING things.
We could maybe do prereleases for all engines, before making it stable.
- **BREAKING CHANGE:** Print additional label on warnings (to separate them from errors) b7c1e17 | ||
- **BREAKING CHANGE:** Drop support for Node 10.x. Now require ESM-compatible Node.js versions: `^12.20.0 || ^14.13.1 || >=16.0.0` #252 | ||
- **BREAKING CHANGE:** the `parseOpts` option to the `StandardEngine` (formerly called `Linter`) constructor has been replaced with a new `resolveEslintConfig` one | ||
- Change: make `--verbose` the default #232 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could argue, that this is also a BREAKING CHANGE as it removes an option from the CLI and it changes the default behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One could pretty much argue that bug fixes are breaking changes as well ;) Depends on what could be perceived as a public API to which one has guaranteed stability. In general I would say that CLI text output should not be treated as a public API unless explicitly stated to be for programmatic use
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing! 🤩
Co-authored-by: Linus Unnebäck <[email protected]>
Prerelease done, update to |
Fixes #234
Just throwing this out here, not thoroughly tested, but all tests pass + all types are okay
Things remaining:
README.md
/ documentation