Repository navigation
AllowJs + ES6 lib result in compiler crash #40251
Description
TypeScript Version: 4.0.2
Search Terms:
typescript Cannot read property 'name' of undefined
Code
For reasons beyond my control, my team has a few node modules checked into our code that we subsequently run through the Typescript compiler as a part of building our front end through the ts-loader Webpack loader. We can probably work around this on our end because this case is special, but I'm reporting this because I have a hunch that there could be other legitimate cases that fall to the same error. Here's a minimal package.json and tsconfig.json that I can use to recreate the problem:
{
"name": "broken-typescript",
"version": "1.0.0",
"scripts": {
"build": "tsc -p tsconfig.json"
},
"dependencies": {
"@okta/okta-signin-widget": "4.3.3",
"typescript": "4.0.2"
}
}{
"compilerOptions": {
"rootDir": "./",
"outDir": "out",
"allowJs": true,
"strict": true,
"lib": ["es6"]
},
"include": [
"./node_modules/@okta/okta-signin-widget/dist/js/okta-sign-in.js"
]
}
Just npm i && npm run build and you'll see the error
Expected behavior:
The compiler finishes without failure
Actual behavior:
An error gets thrown:
TypeError: Cannot read property 'name' of undefined
Activity
frank-dspeed commentedon Aug 27, 2020
That is because https://unpkg.com/browse/@okta/okta-signin-widget@4.3.3/dist/js/okta-sign-in.js is not a JS Module its a webpack module TS does not support importing webpack modules at present.
JimmyPruitt commentedon Aug 27, 2020
The same module works in version 3.9 of Typescript. If you change the TS version in that package ☝️ to
3.9.7and runnpm i && npm build, there are no errors and a file is emitted to the correct directory. Are you saying that this was an undocumented breaking change of version 4?Handle when associated name can be undefined
ahejlsberg commentedon Oct 28, 2020
The root issue is that this produces an error:
To make matters worse, when attempting to report the erroneous error, we crash if there's a rest parameter:
The issue only occurs with a rest parameter of type
never[]and it's caused bycompareSignaturesRelatedassuming thatany(the type used for an unmatched parameter position) is assignable to anything. It is--except fornever. We should change the logic to not even attempt to relate unmatched positions. I will put up a PR to that effect.