-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tsc with allowJs reports TS9005 error for anonymous constructor functions #55172
Comments
I spent too long looking at fixing this before realizing something critical - this isn't a regression, despite what the OP says. The playground doesn't report it, but in 3.6.3 and before, this code emits
because we simply didn't have JS declaration emit at the time at all - it was added in 3.7. So we shouldn't worry about this from a regression perspective. Now, from a usage perspective, I can understand wanting us to do better here, it's just a little odd. We need to do some pretty significant rewriting for symbols like this. This currently doesn't work because we try to emit |
This doesn't seem solved? |
I also have a problem here, and I can't use annotation because it is generated code with prisma client generate. That really cause pain here because my only option would be to downgrade yarn (as the reason why I generate the client in the workspace instead of node_modules is yarn4). Can you please ignore all js error ? I have this one TS9005 and TS9006. Both should be ignored. |
Bug Report
Declaring a constructor function like so:
leads to typescript reporting error "TS9005": Declaration emit for this file requires using private name 'SomeConstructor'. An explicit type annotation may unblock declaration emit.
However the practically equivalent using a named function:
works fine.
It seems to me that the TS compiler should not care which of these notations is used. But even if the difference is intentional, the error message generated seems incorrect or unhelpful and misleading at least. Also the hint to add type annotations seems inappropriate; no amount of explicit type annotations will make this error go away.
Similar errors get generated when using the following constructs:
or
My tsconfig.json:
🔎 Search Terms
typescript TS9005
Declaration emit for this file requires using private name
typescript allowJs error 9005 const function class declaration
typescript allowJs error 9005 anonymous function class declaration
🕗 Version & Regression Information
This also happens in the Nightly version in the playground:
https://www.typescriptlang.org/play?strict=false&noImplicitAny=false&strictFunctionTypes=false&strictPropertyInitialization=false&strictBindCallApply=false&noImplicitThis=false&noImplicitReturns=false&alwaysStrict=false&ts=5.2.0-dev.20230727&filetype=js&strictNullChecks=false#code/MYewdgzgLgBAyiAtgUwMLmgJwK7CiTGAXhgDNsw8BLcGACgEoYBvAKAEgoALKiAOgAexGAEYA3KwC+EoA
It does not happen with versions 3.3.3-3.6.3:
https://www.typescriptlang.org/play?strict=false&noImplicitAny=false&strictFunctionTypes=false&strictPropertyInitialization=false&strictBindCallApply=false&noImplicitThis=false&noImplicitReturns=false&alwaysStrict=false&ts=3.6.3&filetype=js&strictNullChecks=false#code/MYewdgzgLgBAyiAtgUwMLmgJwK7CiTGAXhgDNsw8BLcGACgEoYBvAKAEgoALKiAOgAexGAEYA3KwC+EoA
However this versions also dont generate any typing information (.D.TS).
It seems to start happening with version 3.7.5:
https://www.typescriptlang.org/play?strict=false&noImplicitAny=false&strictFunctionTypes=false&strictPropertyInitialization=false&strictBindCallApply=false&noImplicitThis=false&noImplicitReturns=false&alwaysStrict=false&ts=3.7.5&filetype=js&strictNullChecks=false#code/MYewdgzgLgBAyiAtgUwMLmgJwK7CiTGAXhgDNsw8BLcGACgEoYBvAKAEgoALKiAOgAexGAEYA3KwC+EoA
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
tsc reports error "TS9005": Declaration emit for this file requires using private name 'SomeConstructor'. An explicit type annotation may unblock declaration emit.
This seems wrong because the equivalent code
works fine and it seems that there shouldn't be any relevant differences between these notations for the TS compiler.
🙂 Expected behavior
tsc should be happy
The text was updated successfully, but these errors were encountered: