Would you welcome these contributions and be willing to adjust the package name? about typescript-proto-decorator HOT 6 CLOSED

Pushed some changes, af22ea5...9cd1096.

A unit test PR against the dev branch would definitely be appreciated!

from typescript-proto-decorator.

Hey, thanks for letting me know these proposals exist (I just use Typescript to transpile my code to es5 and include polyfills through polyfill.io).

I'll make a note and look into these over the weekend. In principal, I'm not opposed to supporting esnext decorators, but I'll want to read up on them first to know about any differences etc. I want this package to be as small and efficient as possible, therefore I might opt to just turn this into a monorepo with some common code and publish the es and typescript versions separately.

from typescript-proto-decorator.

Hey, thanks for letting me know these proposals exist [...].

Welcome.

I'll make a note and look into these over the weekend. In principal, I'm not opposed to supporting esnext decorators, but I'll want to read up on them first to know about any differences etc. I want this package to be as small and efficient as possible, therefore I might opt to just turn this into a monorepo with some common code and publish the es and typescript versions separately.

Just to get things 100% straight, there is no "typescript version" of decorators. There is a single decorators proposal for ESnext, which has evolved over time. TypeScript and Babel both currently implement the same old version of this proposal, which you can still find over here. Since this old version is the only version which currently has transpiler support, this is also the version that people are currently using, including your package.

So your package is not specific to TypeScript, even though you probably got the how-to from this page in the TypeScript handbook. This is why I'm suggesting to remove "typescript" from the name of your package and to add some checks so that Babel users can rest assured that your decorator will work for them, too. You are using TypeScript for the implementation of your package and you can continue doing so, but this doesn't have to prevent your users from using a different transpiler.

The latest version of this same decorators proposal is what I linked to above (this one). At some point, transpilers will catch up and start implementing this later version. It would be nice if your decorator would continue to work in this (near) future, which is why I'm proposing to make your decorator forward-compatible.

from typescript-proto-decorator.

Take a look at this PR - did I get the forward compatibility right? Seems to work fine on https://babeljs.io/repl.

from typescript-proto-decorator.

Thanks @Alorel, I left a review. I don't think you got the forward compatibility right, but no wonder with a first blind guess in the dark (as there is currently no way to test new-style decorators).

It's uplifting (if not very surprising) to hear that your decorator appears to work with Babel as well. How about always checking this in the Travis build? Would you appreciate a pull request for that?

from typescript-proto-decorator.

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from typescript-proto-decorator.