Conversation
|
I could separate out the addition of |
theoludwig
left a comment
There was a problem hiding this comment.
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.
| "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.
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.
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.
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.
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.
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 testshould 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 👍 |
theoludwig
left a comment
There was a problem hiding this comment.
Great job! 😊
Nearly ready for merging, there are still some comments to be addressed.
| "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.
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 |
theoludwig
left a comment
There was a problem hiding this comment.
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.
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.
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
Co-authored-by: Linus Unnebäck <linus@folkdatorn.se>
|
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