getTypeAliasInstantiation crashes with TypeError: Cannot read properties of undefined (reading 'get')

[AWare]

Bug Report

🔎 Search Terms

getTypeAliasInstantiation

🕗 Version & Regression Information

between 4.7.0-dev.20220322 and 4.7.0-dev.20220323

• This is a crash
• This changed between versions 4.7.0-dev.20220322 and 4.7.0-dev.20220323

⏯ Playground Link

I haven't been able to extract a minimal test case, as it crashed, without emitting any errors. If you have any advice for how to instrument tsc to help find the location, I'd be happy to run through it and attempt to find a minimal test case.

Unfortunately, I am not able to share the repo.

💻 Code

🙁 Actual behaviour

                throw e;
                ^

TypeError: Cannot read properties of undefined (reading 'get')
    at getTypeAliasInstantiation (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:49357:54)
    at createMarkerType (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:55238:17)
    at _loop_22 (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:55206:45)
    at getVariancesWorker (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:55227:21)
    at getVariances (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:55184:17)
    at structuredTypeRelatedTo (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:54392:41)
    at recursiveTypeRelatedTo (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:53996:30)
    at isRelatedTo (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:53580:25)
    at isPropertySymbolTypeRelated (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:54595:24)
    at propertyRelatedTo (/Users/alex/code/application-v3/node_modules/.pnpm/[email protected]/node_modules/typescript/lib/tsc.js:54631:31)```

### 🙂 Expected behaviour

for typescript not to crash

[RyanCavanaugh]

This call stack might be enough for us to go on. Generally the best way to find out how to get a smaller testcase is to attach to the tsc process with a debugger (generally node --inspect-brk path/to/tsc.js -p path/to/your/project) and then look up the call stack for useful hints.

In this stack I'd check the isRelatedTo frame and check the properties of the incoming types source and target; this will tell you which two types in your program are being related. How to identify the types depends on their kinds, but you're likely to see a symbol with a declarations list which should have an element you can call getTextOfNode on in the console window; this will print the originating declaration of the type.

[AWare]

I haven't quite found the offending code yet, but it seems to be related to the optional variance stuff going on in fastify. I'll make a corresponding second issue there if I can pin it down.

[unicornware]

@RyanCavanaugh i'm experiencing a similar issue with [email protected]. it seems to be somewhat related to using skipLibCheck (i say somewhat because i'm using the option in another tsconfig file, but not getting an error 😅):

4:28:40 lex@FLEXBOOK :: ~/Projects/FLDV/FLDV-P026 ‹main*› » tsc -p tsconfig.typecheck.json                                                                                                   2 ↵
/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:99606
                throw e;
                ^

TypeError: Cannot read properties of undefined (reading 'get')
    at getTypeAliasInstantiation (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:51153:54)
    at createMarkerType (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:57171:17)
    at _loop_23 (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:57136:45)
    at getVariancesWorker (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:57157:21)
    at getVariances (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:57114:17)
    at structuredTypeRelatedToWorker (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:56334:41)
    at structuredTypeRelatedTo (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:55955:30)
    at recursiveTypeRelatedTo (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:55924:30)
    at isRelatedTo (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:55506:25)
    at checkTypeRelatedTo (/Users/lex/Projects/FLDV/FLDV-P026/node_modules/typescript/lib/tsc.js:55166:26)

would i take the same steps you outlined above to narrow down the issue further?

[powerpete]

I've the same issue. I reproduce it with the attached project. buggy.zip

The line

var chart: Chart<"scatter"> = undefined;
chart = new Chart(ctx, { type: 'scatter', data: { datasets: [] } });

will force typescript to throw the "TypeError: Cannot read ..." exception.

buggy.zip

[luixo]

I stumbled upon this error as well and decided to dig a little to the core of the problem. I found out there is a clash of some sort in case of an import of an augmented type.

I made a repo with a not really minimal reproduction, but as good as possible. Repo consists of the initial create-next-app commit and a repro with a problem added. Running npm i && npx tsc in the repo outputs given error.

The imported appWithTranslation function uses AppProps from next package, AppProps relies on AppPropsType which relies on AppInitialProps which I augment in pages/_app.tsx file.

Any of those actions will remove the error:

• Removing AppInitialProps augmentation
• Removing appWithTranslation from usage (say, moving it to console.log(appWithTranslation)) effectively factoring it out from calculations
• Changing Props extends NextJsAppProps<any> to Props extends any in next-i18next/dist/types/appWithTranslation.d.ts to Props extends any effectively factoring out the problem type from calculations

Unfortunately, I was not able to create a smaller reproducible case.

I believe this it not the expected behaviour of the tsc and I hope this issue will get addressed.

Possible temporary workaround: Discover the exact type that gives you an error:

function getTypeAliasInstantiation(symbol, typeArguments, aliasSymbol, aliasTypeArguments) {
  var type = getDeclaredTypeOfSymbol(symbol);
  if (type === intrinsicMarkerType && intrinsicTypeKinds.has(symbol.escapedName) && typeArguments && typeArguments.length === 1) {
  return getStringMappingType(symbol, typeArguments[0]);
  }
  var links = getSymbolLinks(symbol);
+   if (!links.instantiations) {
+     console.log('Links', links.escapedName, links);
+   }
  var typeParameters = links.typeParameters;
  var id = getTypeListId(typeArguments) + getAliasId(aliasSymbol, aliasTypeArguments);

..and remove the augmentation.

[huw]

@luixo Thank you! In my case, an upstream dependency updated a type I was importing to add a type parameter, meaning that I was attempting to augment a generic type without supplying the parameters correctly. Easy to solve once I knew what was going on!

[dmortimer]

Currently experiencing this issue as well - not sure if there was any resolution. Just checking that before posting a reproduction of my application.

[RyanCavanaugh]

We don't have a solid/minimal repro yet; one would be greatly appreciated

[luixo]

We don't have a solid/minimal repro yet; one would be greatly appreciated

Can you please specify what my reproduction (mentioned above) lacks?

[RyanCavanaugh]

16 files plus whatever npm brings in is not minimal

[LelouBil]

Here is a repro with only typescript as a dependency, and the smallest file content I could find https://github.com/LelouBil/typescript-bug-repro

[LelouBil]

I didn't manage to simplify the example further

[RyanCavanaugh]

Based on the repro and call stack, this is a duplicate of #53287

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.