Skip to content
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

Tighter parameter decorator checking with --experimentalDecorators #52435

Closed
DanielRosenwasser opened this issue Jan 26, 2023 · 8 comments
Closed
Labels
Breaking Change Would introduce errors in existing code Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jan 26, 2023

// @experimentalDecorators: true
export declare const Inject:
  (entity: Function, dataSource?: string) =>
    (target: object, key: string | symbol, index?: number) => void;

export class Foo {}

export class C {
  constructor(@Inject(Foo) x: any) {  }
}

Previously: no error
In main/5.0:

Unable to resolve signature of parameter decorator when called as an expression.
  Argument of type 'undefined' is not assignable to parameter of type 'string | symbol'
@DanielRosenwasser DanielRosenwasser added the Bug A bug in TypeScript label Jan 26, 2023
@DanielRosenwasser
Copy link
Member Author

Was this...possibly always a bug with --experimentalDecorators?

@DanielRosenwasser DanielRosenwasser changed the title Decorator call resolution regression with --experimentalDecorators Decorator call regression with --experimentalDecorators Jan 26, 2023
@DanielRosenwasser DanielRosenwasser added Breaking Change Would introduce errors in existing code and removed Bug A bug in TypeScript labels Jan 26, 2023
@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Jan 26, 2023

Yes, it seems this was a bug in type-checking parameter decorators on constructors under --experimentalDecorators with TypeScript 4.9 and prior.

In #50820, we fixed up the way we type-checked decorators. This catches some issues, like decorators which expect a defined key; however, parameter decorators in constructors don't get passed a key. As a result, libraries with dependency injection decorator functions like inversify (pre-6.0), NestJS, and others (often named inject, Inject, and InjectRepository) might need to be corrected to accept an undefined key (or to have an overload which accepts an undefined key).

@DanielRosenwasser DanielRosenwasser added this to the TypeScript 5.0.0 milestone Jan 26, 2023
@DanielRosenwasser DanielRosenwasser changed the title Decorator call regression with --experimentalDecorators Tighter parameter decorator checking with --experimentalDecorators Jan 26, 2023
@DanielRosenwasser DanielRosenwasser added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jan 26, 2023
@rbuckton
Copy link
Member

rbuckton commented Jan 26, 2023

inversify's @inject works fine starting in [email protected]. @nestjs/common's @inject needs to be updated, however.

@kevinlul
Copy link

Is tsyringe affected?

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Jan 27, 2023

Yes, I believe so.

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Jan 27, 2023

I filed an issue at NestJS over at #52435. I'm not sure how active TSyringe is at the moment.

@typescript-bot
Copy link
Collaborator

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

@Evaldoes
Copy link

Evaldoes commented Jan 7, 2024

I was able to solve this problem by adding these parameters to the tsconfig.json file:

I used inversify: 6.0.1 version

NOTE: when I inserted it at the end of the file it didn't work, only when I put it at the beginning

{
  "compilerOptions": {
      "emitDecoratorMetadata": true,
      "experimentalDecorators": true,
      "allowJs": true,
  }
}

I hope I can help 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Would introduce errors in existing code Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants