Skip to content

typescript-eslint recommended rules don't apply to gts files #119

@bendemboski

Description

@bendemboski

Repro

$ pnpm dlx ember-cli@latest addon my-addon -b @ember/addon-blueprint --pnpm --typescript
$ cd my-addon
$ echo 'export default function(assert: Assert) { return assert; }' > src/foo.ts
$ echo 'export default function(assert: Assert) { return assert; }' > src/bar.gts
$ pnpm lint:js

Expected

Linting passes

Actual

It passes for the .ts file, but not the .gts file:

> [email protected] lint:js /private/tmp/my-addon
> eslint . --cache


/private/tmp/my-addon/src/bar.gts
  1:33  error  'Assert' is not defined  no-undef

✖ 1 problem (1 error, 0 warnings)

 ELIFECYCLE  Command failed with exit code 1.

Discussion

The problem is here. ts.configs.recommendedTypeChecked specifies a files array, but as outlined in the tseslint.config to defineConfig migration guide, overriding the files array (now) results in the intersection of the two arrays, which in this case ends up just being ts, so it doesn't apply to gts files and therefore, among other things, doesn't turn off no-undef.

I can't see a super clean way to address this directly because I don't think typescript-eslint exports just that recommended ruleset without the files specified. Perhaps we should PR the addition of gts to that files array (and any other relevant files arrays in typescript-eslint)? In the near term, we could work around it by switching back to the deprecated tseslint.config(), or with some non-ideal hackery:

    {
      files: ['**/*.{ts,gts}'],
      // *snip*
      extends: [
        ...ts.configs.recommendedTypeChecked.map((entry) => {
          const processed = { ...entry };
          delete processed.files;
          return processed;
        }),
        ember.configs.gts,
      ],
    },

I'm happy to PR a change into typescript-eslint but perhaps somebody else in the community already has a relationship and would be more likely to have the PR accepted if they were the author? Also happy to open a PR into this repo for one of the workarounds with some guidance on which way we think we want to go.

NOTE: this also affects the app blueprint.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions