Ron Buckton

> reflect-metadata doesn't appear to be written in CJS, but also doesn't appear to be a valid ES module (i.e. it doesn't have "type": "module" or an .mjs extension for...

I realize it's a bit late, but I've added releases and git tags for 0.1.13 and the more recent releases, and will do a better job about tagging releases in...

That is out of scope for `reflect-metadata`, as this package does not control what is available to decorators itself. TypeScript's `--experimentalDecorators` do not provide this, though I am considering it...

This isn't a change we will take per the reasoning I referenced above. Please note that the Stage 3 Decorator Metadata proposal does work with proxies, since it uses a...

I'm not comfortable taking this PR as I'm not familiar with what `window.wrappedJSObject` is, and how this change might affect other consumers of the library. The test seems fairly fragile...

Now that the [Decorator Metadata](https://github.com/tc39/proposal-decorator-metadata) is at Stage 3, it is unlikely that this proposal will be brought to committee.

You would need to check the generated output to see if a `__metadata()` call is issued for the `multiply` method. Unfortunately, I cannot speak to what level of support vite,...

Closing as it seems the original question has been answered. As far as the value of `design:paramtypes`, the behavior of TypeScript's `--emitDecoratorMetadata` behavior is better discussed on the TypeScript repository.

Closing this as External. Class decorators should always return either `undefined`, or a replacement constructor. Returning a non-callable `object` is not supported in either TypeScript's `--experimentalDecorators` mode, nor in the...

Closing in favor of #144.