webpack brings in @types/eslint @v8, so ember-cli-typescript could detect that and bring in @types/eslint @v7, so that a basic ember app doesn't default to failure?

[NullVoxPopuli]

trafficstars

Please paste the output of ember -v here

❯ ember -v
ember-cli: 4.3.0
node: 16.13.1
os: linux x64

Please paste the output of tsc -v here

❯ pnpm exec tsc -v
Version 4.6.4

Please paste the version of ember-cli-typescript and ember-cli-typescript-blueprints here

❯ cat package.json | grep typescript
    "ember-cli-typescript": "^5.1.0",
    "ember-cli-typescript-blueprints": "^3.0.0",
    "typescript": "^4.6.4",

Please paste your tsconfig.json and tslint.json or eslint.json (if applicable) below

My tsconfig.json

{
  "compilerOptions": {
    "target": "ES2021",
    "module": "ES2020",
    "moduleResolution": "node",

    // Trying to check Ember apps and addons with `allowJs: true` is a recipe
    // for many unresolveable type errors, because with *considerable* extra
    // configuration it ends up including many files which are *not* valid and
    // cannot be: they *appear* to be resolve-able to TS, but are in fact not in
    // valid Node-resolveable locations and may not have TS-ready types. This
    // will likely improve over time
    "allowJs": false,

    // --- TS for SemVer Types compatibility
    // Strictness settings -- you should *not* change these: Ember code is not
    // guaranteed to type check with these set to looser values.
    "strict": true,
    "noUncheckedIndexedAccess": true,

    // Interop: these are viral and will require anyone downstream of your
    // package to *also* set them to true. If you *must* enable them to consume
    // an upstream package, you should document that for downstream consumers to
    // be aware of.
    //
    // These *are* safe for apps to enable, since they do not *have* downstream
    // consumers; but leaving them off is still preferred when possible, since
    // it makes it easier to switch between apps and addons and have the same
    // rules for what can be imported and how.
    "allowSyntheticDefaultImports": false,
    "esModuleInterop": false,

    // --- Lint-style rules

    // TypeScript also supplies some lint-style checks; nearly all of them are
    // better handled by ESLint with the `@typescript-eslint`. This one is more
    // like a safety check, though, so we leave it on.
    "noPropertyAccessFromIndexSignature": true,

    // --- Compilation/integration settings
    // Setting `noEmitOnError` here allows ember-cli-typescript to catch errors
    // and inject them into Ember CLI's build error reporting, which provides
    // nice feedback for when
    "noEmitOnError": true,

    // We use Babel for emitting runtime code, because it's very important that
    // we always and only use the same transpiler for non-stable features, in
    // particular decorators. If you were to change this to `true`, it could
    // lead to accidentally generating code with `tsc` instead of Babel, and
    // could thereby result in broken code at runtime.
    "noEmit": true,

    // Ember makes heavy use of decorators; TS does not support them at all
    // without this flag.
    "experimentalDecorators": true,

    // Support generation of source maps. Note: you must *also* enable source
    // maps in your `ember-cli-babel` config and/or `babel.config.js`.
    "declaration": true,
    "declarationMap": true,
    "inlineSourceMap": true,
    "inlineSources": true,

    // The combination of `baseUrl` with `paths` allows Ember's classic package
    // layout, which is not resolveable with the Node resolution algorithm, to
    // work with TypeScript.
    "baseUrl": ".",
    "paths": {
      "repro-glint-gts-error-parse-node/tests/*": [
        "tests/*"
      ],
      "repro-glint-gts-error-parse-node/*": [
        "app/*"
      ],
      "*": [
        "types/*"
      ]
    }
  },
  "include": [
    "app/**/*",
    "tests/**/*",
    "types/**/*"
  ]
}

What are instructions we can follow to reproduce the issue?

ember new my-app
cd my-app
ember install ember-cli-typescript
ember s 
# => errors

Reproduction Case

I have this repo, which I was trying to repo an unrelated error:

• https://github.com/NullVoxPopuli/repro-glint-gts-error-parse-node

See commits: https://github.com/NullVoxPopuli/repro-glint-gts-error-parse-node/commits/main

the error is present from the 3rd commit https://github.com/NullVoxPopuli/repro-glint-gts-error-parse-node/commit/10fe083833b379a43475003721ffa8ae233913cf

all the way until the work around is implemented: https://github.com/NullVoxPopuli/repro-glint-gts-error-parse-node/commit/6e93bbd527a1ad5fe9fc21868dfa9695de0b7846

What happened instead?

❯ pnpm start

> [email protected] start /home/nullvoxpopuli/Development/NullVoxPopuli/repro-glint-gts-error-parse-node
> ember serve

Building into /tmp/embroider/d85e90
node_modules/.pnpm/@[email protected]/node_modules/@types/eslint/helpers.d.ts:1:6 - error TS2300: Duplicate identifier 'Prepend'.

1 type Prepend<Tuple extends any[], Addend> = ((_: Addend, ..._1: Tuple) => any) extends (..._: infer Result) => any
       ~~~~~~~

  node_modules/.pnpm/@[email protected]/node_modules/@types/eslint/helpers.d.ts:1:6
    1 type Prepend<Tuple extends any[], Addend> = ((_: Addend, ..._1: Tuple) => any) extends (..._: infer Result) => any
           ~~~~~~~
    'Prepend' was also declared here.

node_modules/.pnpm/@[email protected]/node_modules/@types/eslint/helpers.d.ts:1:6 - error TS2300: Duplicate identifier 'Prepend'.

1 type Prepend<Tuple extends any[], Addend> = ((_: Addend, ..._1: Tuple) => any) extends (..._: infer Result) => any
       ~~~~~~~

  node_modules/.pnpm/@[email protected]/node_modules/@types/eslint/helpers.d.ts:1:6
    1 type Prepend<Tuple extends any[], Addend> = ((_: Addend, ..._1: Tuple) => any) extends (..._: infer Result) => any
           ~~~~~~~
    'Prepend' was also declared here.

Typechecking failed


Stack Trace and Error Report: /tmp/error.dump.d886b2fe0a282fb330b985fc9be9f695.log
node:internal/process/promises:227
        triggerUncaughtException(err, true /* fromPromise */);
        ^

Error: Typechecking failed

[chriskrycho]

You can use skipLibCheck for this if need be, though it's unclear why type checking is getting involved in @types/eslint unless you're writing ESLint rules.

Pretty confident we're not going to try to do detection like this in any case; the combinatorial explosion of things we would need to try to account for is very large. The right solution, as always, is to do the (admittedly quite annoying) work to resolve these kinds of discrepancies in your dependencies.

[NullVoxPopuli]

h it's unclear why type checking is getting involved in

This is pretty sus: https://github.com/webpack/webpack/blob/main/package.json#L8-L9

The right solution,

right, but for "SEO" purposes, folks using typescript and ember will check here first, and it's important to have reasons, discussions, correct guidance, to be easily discoverable :partying_face:

[NullVoxPopuli]

oh wow, webpack makes you sign a docusign thing before they'll review your PR :thinking:

[jacobq]

oh wow, webpack makes you sign a docusign thing before they'll review your PR 🤔

I haven't read their CLA, but my employer has not placed legal restrictions on my FOSS work, so let me know if you're unable to do it and would like me to do something by proxy.

[NullVoxPopuli]

thanks <3 I was just trying to fix this in my free time on the couch, and now it seems a bunch of non-contributors are arguing on the PR? idk. it's weird

[rreckonerr]

Hi! Do you have a solution for that? Hitting the same issue

[NullVoxPopuli]

closing this because eslint7 isn't used in any of my projects

[IgnaceMaes]

I ran into a similar issue. My problem was that multiple @types/eslint versions were mixed.

Was able to resolve this by deduping the dependency in the lockfile:

yarn dedupe @types/eslint