Skip to content
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

Merged
merged 20 commits into from Nov 30, 2021
Merged

Initial port to new ESLint API #275

merged 20 commits into from Nov 30, 2021

Conversation

voxpelli
Copy link
Member

@voxpelli voxpelli commented Nov 22, 2021

Fixes #234

Just throwing this out here, not thoroughly tested, but all tests pass + all types are okay

Things remaining:

  • Update README.md / documentation

@voxpelli
Copy link
Member Author

I could separate out the addition of dependency-check, installed-check and npm-run-all from this PR, but they added good assistance in helping to assure that I was on the right path.

@voxpelli voxpelli marked this pull request as ready for review November 22, 2021 22:44
@voxpelli voxpelli changed the title Initial port to new api Initial port to new ESLint API Nov 22, 2021
Copy link
Member

@theoludwig theoludwig left a 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.

bin/cmd.js Outdated Show resolved Hide resolved
bin/cmd.js Outdated Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
lib/resolve-eslint-config.js Outdated Show resolved Hide resolved
lib/resolve-eslint-config.js Outdated Show resolved Hide resolved
package.json Outdated
Comment on lines 38 to 45
"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:*"
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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. 👍

test/api.js Outdated Show resolved Hide resolved
@voxpelli voxpelli added this to the 15.0.0 milestone Nov 29, 2021
@voxpelli
Copy link
Member Author

Tweaked and fixed things here, this should now be much more ready for merge 👍

Copy link
Member

@theoludwig theoludwig left a 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.

.github/workflows/lint.yml Outdated Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
package.json Outdated
Comment on lines 38 to 45
"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:*"
Copy link
Member

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.

@voxpelli
Copy link
Member Author

Updated README + CHANGELOG now as well

Copy link
Member

@theoludwig theoludwig left a 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
Copy link
Member

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.

Copy link
Member Author

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

@voxpelli voxpelli requested a review from feross November 30, 2021 06:58
CHANGELOG.md Outdated Show resolved Hide resolved
Copy link
Member

@LinusU LinusU left a comment

Choose a reason for hiding this comment

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

Amazing! 🤩

@voxpelli voxpelli merged commit 5f66f04 into master Nov 30, 2021
@voxpelli voxpelli deleted the port-to-new-api branch November 30, 2021 10:27
@voxpelli
Copy link
Member Author

@divlo @LinusU Should we do a prerelease of 15.0.0 right away?

@theoludwig
Copy link
Member

@divlo @LinusU Should we do a prerelease of 15.0.0 right away?

Yes, that would help. 👍 @voxpelli
So we can already open PRs in the multiple engines (standard, standardx, ts-standard, semistandard) using this prerelease version, as there are probably multiple things that need to change.

@voxpelli
Copy link
Member Author

Prerelease done, update to master pending in #282

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Usage of deprecated APIs of ESLint
3 participants