Consider supporting reflect-metadata@^0.2.1

[notaphplover]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

NestJs libraries have a peer dependency of reflect-metadata@^0.1.12, so 0.2.X versions are not supported (consider docs) as reference.

Describe the solution you'd like

Since reflect-metadata@0.2.X are not introducing any breaking changes, it would be great if they could be accepted in the range of the peer dependencies.

Teachability, documentation, adoption, migration strategy

The migration strategy would consist in updating package peer dependencies to also allow reflect-metadata@0.2.X

What is the motivation / use case for changing the behavior?

Updating reflect-metadata dependencies of my packages that are implemented on top of the NestJS framework.

[schiller-manuel]

Should nestjs then use the newly introduced reflect-metadata/lite export?
see rbuckton/reflect-metadata#144

[KostyaTretyak]

Should nestjs then use the newly introduced reflect-metadata/lite export? see rbuckton/reflect-metadata#144

From the linked PR:

The polyfill-free /lite and /no-conflict exports require a runtime or bundler that supports package.json subpath exports.

So, as far as I understand, reflect-metadata/lite will be used in NestJS only after migration to ECMAScript modules.

[schiller-manuel]

Is the migration to ESM on the horizon?

[kamilmysliwiec]

#12943

[notaphplover]

@kamilmysliwiec there seems to be trouble in the CI to merge #12943, would it be ok if we submit a PR to properly update the constraints? Once its merged it will allow renovatebot to properly update example packages.