ci: run against upcoming next major ESLint version #1534
Conversation
G-Rath
force-pushed
the
run-ci-against-9
branch
7 times, most recently
from
e84b02a
to
a4b95d7
Compare
|
It seems like ESLint v9 somehow has different globals resulting in |
G-Rath
force-pushed
the
run-ci-against-9
branch
from
d77a688
to
d62e847
Compare
G-Rath
force-pushed
the
run-ci-against-9
branch
from
d62e847
to
05bae05
Compare
|
Seems that I've confirmed this is only a development problem - everything works fine on a standard project that's using |
G-Rath
force-pushed
the
run-ci-against-9
branch
3 times, most recently
from
5c07150
to
6b74595
Compare
G-Rath
force-pushed
the
run-ci-against-9
branch
from
6b74595
to
4906b85
Compare
jest.config.ts
Outdated
| coveragePathIgnorePatterns: ['/node_modules/'], | ||
| }, | ||
| ], | ||
| } satisfies Config.InitialOptions; |
There was a problem hiding this comment.
| } satisfies Config.InitialOptions; | |
| } satisfies Config; |
why satisfies instead of assigning?
There was a problem hiding this comment.
because assigning means it is Config - so all properties marked as required are such, and optional ones are that outside of the assignment; so TypeScript won't let us do things on those properties later down without existence checks - sadly it's not perfect: we've got to define properties we want to use since the type information is not retained after the assignment, which is why we've got coveragePathIgnorePatterns explicitly defined with its default values.
Having said that, I've not checked out Config.InitialOptions so that might change things
There was a problem hiding this comment.
Ok so jest.Config is just a re-export of Config.InitialOptions - so yeah, we could do either or; I think using satisfies is slightly nicer though.
To make it a bit clearer:
that's what happens if you use assignment, and it's because to TypeScript config is type Config rather than the actual object we created.
| @@ -154,6 +155,20 @@ describe('the rule', () => { | |||
| expect(() => { | |||
| const linter = new TSESLint.Linter(); | |||
|
|
|||
| /* istanbul ignore if */ | |||
| if (usingFlatConfig()) { | |||
There was a problem hiding this comment.
Because we're effectively running ESLint here per usual - so when using ESLint v9 we have to use flatconfig and when using pre-v9 we have to use legacy config.
While linter.verify supports being passed both types of configs, since we have call defineRule in pre-v9 (which errors in v9) this felt the cleanest way to address it (though either way we'll always need usingFlatConfig.
|
|
||
| export class FlatCompatRuleTester extends TSESLint.RuleTester { | ||
| public constructor(testerConfig?: TSESLint.RuleTesterConfig) { | ||
| super(FlatCompatRuleTester._flatCompat(testerConfig)); |
There was a problem hiding this comment.
is it ok to use this private thing?
There was a problem hiding this comment.
it's our private thing so yes :)
(its static since this is in the constructor and it felt a little nicer than having it as an external function)
|
🎉 This PR is included in version 28.0.0-next.7 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 28.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Hopefully this'll just work...it did not, but now it does!