Error running eslint --fix when multiple .gts files are present
#119
Comments
|
Oh, another note -- at @NullVoxPopuli's suggestion I tried removing the prettier plugin from the linting config, but that doesn't affect anything -- we still get this same error. |
|
Here is a more minimal repro. I have also confirmed that the error only happens if two |
|
This appears to be a compatibility issue with |
|
@bendemboski Downgrading to v7 fixed it for me as well! |
|
Ah... i have reportes this error also here ember-cli/eslint-plugin-ember#2240 When we use TS <= 5.5 the issue is fixed |
|
I believe the fix for this issue is to add I definitely don't fully grok everything here, but @NullVoxPopuli if you can help me get a branch of this repo that reproduces the error, I would happily and eagerly test & PR this fix. |
In the `sourceFile` objects that `typescript` manages, `gts` files end up with an `impliedNodeFormat` of `undefined` and `mts` files end up with an `impliedNodeFormat` of `99`. The buckets that `typescript` uses to cache the source files are keyed by their format, so when we run this syncing logic on an existing `mts` file we were overwriting its `impliedNodeFormat` and setting it to `undefined`. Perhaps something changed in `typescript-eslint@8` to take advantage of more caching or program reuse, not sure, but the result is that overwriting the `impliedNodeFormat` of the `mts` files that correspond to un-fixed `gts` files causes the error in ember-tooling#119. Adding it to the list of fields to preserve fixes it in all the cases I've run.
Repro
npx [email protected] new my-app --pnpm --typescriptcd my-appecho -e 'const Foo = <template></template>;\nexport default Foo;' > app/components/foo.gtsecho -e '// eslint-disable-next-line prefer-const\nconst Bar = <template></template>;\nexport default Bar;' > app/components/bar.gtspnpm lint:js:fixResult
The unused
eslint-disable-next-linecomment is deleted, but the now-blank line is not removed, and the following error occurs:Analysis
The proximate cause of the error is that
isDocumentRegistryEntry()is called withundefinedrather than a valid entry. This is happening becausereleaseDocumentWithKeyis being called with a path of/private/tmp/my-app/app/components/bar.mts, but there's no corresponding value in bucket, it only containsSo my guess is that the
ts-patch.tsstuff this parser does is causing thesemtsentries to get added somewhere but then not handled properly.The only other clue that I noticed is that further up the stack is a function called
tryReuseStructureFromOldProgram, and it looks like we're hitting an error in the process of trying to find info about files in an old typescript "program" so maybe we can reuse that info in the new "program"? So (wildly guessing here) perhaps we build a typescript program, run the lint-fixing, but then rerun it to see if other linters have new fixes to apply, and the ts-patching this parser does leavesmtsentries in the old program that this try-reuse logic trips over.The text was updated successfully, but these errors were encountered: