Is this compatible with TS 5 decorators?

[ffMathy]

Typescript 5.0 recently released. It changes decorators quite a bit.

Will this library work without the experimental decorators flag? I think that should be written in the Readme somewhere.

[South-Paw]

Is there any plans by the team or community to update this package to support TS 5.0?

[rfire12]

None of the maintainers seem to be working at microsoft. Not sure if they ever did, as I just started using this library recently.

So I guess the future of this project seem to be uncertain, as there hasn't been much activity either lately.

[South-Paw]

None of the maintainers seem to be working at microsoft. Not sure if they ever did, as I just started using this library recently.

So I guess the future of this project seem to be uncertain, as there hasn't been much activity either lately.

The library is stable, has all the features it needs implemented and has been in that state for ages.

[stevenulibarri]

None of the maintainers seem to be working at microsoft. Not sure if they ever did, as I just started using this library recently. So I guess the future of this project seem to be uncertain, as there hasn't been much activity either lately.

The library is stable, has all the features it needs implemented and has been in that state for ages.

Technically yes, but I think we should expect TS to cease supporting experimental decorators eventually. But its more likely that users of tsyringe may eventually encounter a package they want to use that requires the new decorators but can't until it becomes compatible. But even then, that compatibility is not trivial, the new decorator spec does not support parameter injection at all and probably won't for a long time. In my own case its not a ton of work to remove instances of parameter injection from my projects but for others it might be more difficult. Its an unfortunate situation all around.

[wenindoubt]

Does anyone have experience using another stable, lightweight DI framework that is more actively maintained?

EDIT: It turns out that I don't need any fancy features that a framework offers. I've decided to go Pure DI.

[ffMathy]

I ended up going for Inversify.

[South-Paw]

None of the maintainers seem to be working at microsoft. Not sure if they ever did, as I just started using this library recently. So I guess the future of this project seem to be uncertain, as there hasn't been much activity either lately.

The library is stable, has all the features it needs implemented and has been in that state for ages.

Technically yes, but I think we should expect TS to cease supporting experimental decorators eventually. But its more likely that users of tsyringe may eventually encounter a package they want to use that requires the new decorators but can't until it becomes compatible. But even then, that compatibility is not trivial, the new decorator spec does not support parameter injection at all and probably won't for a long time. In my own case its not a ton of work to remove instances of parameter injection from my projects but for others it might be more difficult. Its an unfortunate situation all around.

I agree - I want to see this package support TS 5 decorators as well or a fork that does and works with TS 5 so we aren't locked out of other newer decorator packages.

However let's not forget that we were all using a flag that does actually say it is experimental on it's doc page and as such we knew this could or would happen eventually when decorator support got closer to being finalised 😄

On my reply, it was only to the comment of "future of this project seem to be uncertain, as there hasn't been much activity either lately". Just because a project doesn't have recent activity, doesn't mean its broken or out of date. Some libraries you have in your dependency trees haven't had updates for years and remain stable, secure and reliable despite this fact. reflect-metadata (which up until TS 5 has been the thing to use if you're using decorators with the emitDecoratorMetadata option) hasn't been committed to since 2019.... you can see this for yourself.

But let's try avoid getting into that whole topic, instead let's just focus on what we do with this package and TS 5 as it'll actually lead to some results for us all rather than a pointless argument on semantics 👍

[jhechtf]

In looking through the code it seems like this may have already been resolved via https://github.com/microsoft/tsyringe/pull/226 but it simply hasn't been published yet.

Hopefully once that becomes published it should work without issue in TS 5.x environments.

[jhechtf]

Are there any plans to release the code changes that would publish the TS5 compatibility any time soon? PR looks like it was merged some time ago.

[PodaruDragos]

I ended up going for Inversify.

inversify also uses Reflect.metadata so it won't work with TS 5 decorators.

[jhechtf]

I ended up going for Inversify.

inversify also uses Reflect.metadata so it won't work with TS 5 decorators.

Just tested, inversify is not affected by this with version 6.0.1

[nazrhyn]

@MeltingMosaic had merge capability, but sometimes it's different people who can publish new versions to NPM. I guess they'd also have to evaluate whether the other changes in master since the last published version are okay to publish.

[Aldiwildan77]

Any updates for these releases?

[yatiac]

Upgraded TS to v5 and now I am facing this 😢

[stevenulibarri]

I don't really understand what is happening with the repo. The PR that would allow moving to the latest TS version was merged and the action ran for the release, its green and everything, but NPM still shows 4.7.0 which is over a year old now. https://github.com/microsoft/tsyringe/actions/runs/4716091295

[jhechtf]

I don't really understand what is happening with the repo. The PR that would allow moving to the latest TS version was merged and the action ran for the release, its green and everything, but NPM still shows 4.7.0 which is over a year old now. https://github.com/microsoft/tsyringe/actions/runs/4716091295

In looking at that job you mentioned, the steps required to publish the package never ran, so the workflow didn't actually end up doing anything.

This means that someone from the team needs to push a publishing commit so that these changes can go live.

[stevenulibarri]

I am unfamiliar with github actions so I wasn't sure if that meant they were disabled or if I just didn't have access to see more detail about the steps. In any case hopefully a maintainer can just get it shipped; I really don't want to have to fork anything or look for other options if it can be avoided.

[jhechtf]

I am unfamiliar with github actions so I wasn't sure if that meant they were disabled or if I just didn't have access to see more detail about the steps. In any case hopefully a maintainer can just get it shipped; I really don't want to have to fork anything or look for other options if it can be avoided.

yeah me too. i have a project built using tsyringe that id rather not have to move to inversify.

[vajahath]

may be we should ping them on twitter I guess..

[AmauryD]

Just forked and published to npm while waiting for the real package to update. @triptyk/tsyringe .

[jhechtf]

@Xapphire13 Hoping to get some traction on getting the changes for TS5 support published.

[wielski]

To avoid type error just place .d.ts file in root of your project, like tsyringe.types.d.ts with following contents:

import * as tsyringe from 'tsyringe';

// Overwrite wrong declaration from tryringe, support typescript 5.x
// Remove this when library will update
declare module 'tsyringe' {
  declare function inject(
    token: tsyringe.InjectionToken<any>
  ): (target: any, propertyKey: string | symbol | undefined, parameterIndex: number) => any;
}

It's a little hackish but at least it will work until package will be updated

[m-salman-afzal]

To avoid type error just place .d.ts file in root of your project, like tsyringe.types.d.ts with following contents:

import * as tsyringe from 'tsyringe';

// Overwrite wrong declaration from tryringe, support typescript 5.x
// Remove this when library will update
declare module 'tsyringe' {
  declare function inject(
    token: tsyringe.InjectionToken<any>
  ): (target: any, propertyKey: string | symbol | undefined, parameterIndex: number) => any;
}

It's a little hackish but at least it will work until package will be updated

@wielski It works fine if you are just using tsc. Even VS code has no problems. But ts-node or ts-node-dev are giving the same error like it can't find our custom file. Any workaround that?

[m-salman-afzal]

got it working with --files flag that checks with the typeRoots option in tsconfig

[jhechtf]

Any comment about when this is going to be released? At this rate i might as well move myself to Inversify.

[vajahath]

I'm wondering what other DI frameworks are being used in other popular microsoft projects because this is not actively maintained. tsc itself is from ms. Many projects moved to tsc5 (eg vscode). So these tsc5 moved projects' di lib could be not tsyringe, something else. Not sure if we are missing something.

[woehrl01]

There was a new release published today to npm, in 4.8.0 this change is now included.

[MeltingMosaic]

Sorry folks - I thought I published a new version when I merged the change. Turns out, I did not.

[South-Paw]

@MeltingMosaic Thanks!

[m-salman-afzal]

I think this issue can be closed now.

[Frikki]

@MeltingMosaic So, will the new version be published?

[stevenulibarri]

@Frikki It was published; npm shows v4.8.0 now (published on 6/20) but here on github the releases page hasn't been updated since v4.4.0.

[JobaDiniz]

I'm using typescript 5 and tried to use this library, but VSCode complains with:

Unable to resolve signature of class decorator when called as an expression

Decorators are not valid here

tsconfig.json

"compilerOptions": {
      "experimentalDecorators": true,
      "emitDecoratorMetadata": true,
      "baseUrl": "src/",
      "declaration": true,
      "declarationDir": "build/",
      "emitDeclarationOnly": true,
      "esModuleInterop": true,
      "target": "ESNext",
      "useDefineForClassFields": true,
      "module": "ESNext",
      "lib": [
         "ESNext",
         "DOM",
         "DOM.Iterable",
         "ES2021.String"
      ],
      "moduleResolution": "Node",
      "strict": true,
      "resolveJsonModule": true,
      "isolatedModules": true,
      "noUnusedLocals": false,
      "noUnusedParameters": false,
      "noImplicitReturns": true,
      "skipLibCheck": true,
      "typeRoots": [
         "node_modules/@types"
      ]

Not sure how to move forward :(

[pclokcer]

I'm using typescript 5 and tried to use this library, but VSCode complains with:

Unable to resolve signature of class decorator when called as an expression

Decorators are not valid here

tsconfig.json

"compilerOptions": {
      "experimentalDecorators": true,
      "emitDecoratorMetadata": true,
      "baseUrl": "src/",
      "declaration": true,
      "declarationDir": "build/",
      "emitDeclarationOnly": true,
      "esModuleInterop": true,
      "target": "ESNext",
      "useDefineForClassFields": true,
      "module": "ESNext",
      "lib": [
         "ESNext",
         "DOM",
         "DOM.Iterable",
         "ES2021.String"
      ],
      "moduleResolution": "Node",
      "strict": true,
      "resolveJsonModule": true,
      "isolatedModules": true,
      "noUnusedLocals": false,
      "noUnusedParameters": false,
      "noImplicitReturns": true,
      "skipLibCheck": true,
      "typeRoots": [
         "node_modules/@types"
      ]

Not sure how to move forward :(

I am facing same error

[shawnallen85]

Any update on this working with TS5?

[exuanbo]

Hey everyone, I have been working on a library called di-wise. It has a similar but more powerful API that uses ECMAScript Stage 3 decorators introduced in TS 5. Welcome to try it out.