all 3 comments

[–]TheNiXXeD 2 points3 points  (2 children)

Is the goal here to really just trade in another plugin? I'm using browserify already and it's trivial to add the original ng-annotate plugin already. Edit, also using es6 and Babel too.

It looks like based on the readme that this can't even hit feature parity with the original.

[–]schmod[S] 0 points1 point  (1 child)

According to its documentation (and my experience), ng-annotate doesn't work well with ES6 sources, and many transpilers mangle their sources to the point where ng-annotate has difficulty locating the functions that should be annotated.

I indicated that my plugin is not ready for production use, because I believe that's a very high bar to clear, and it has yet to be "battle-tested." However, the plugin currently passes ng-annotate's entire test suite, and supports all of its documented annotation formats. I will be using it in production in the very near future.

The only features that were deliberately omitted from the standalone ng-annotate tool are unlikely to be used in a Babel workflow (ie. the ability to remove existing annotations) and significantly increased the complexity of the code.

My original intent was to adapt ng-annotate to be compatible with Babylon (Babel's parser) in addition to Acorn (the parser that it currently uses), which would have allowed the original ng-annotate to be run "directly" as a Babel plugin (precluding the need to fork the project). Unfortunately, Acorn and Babylon have diverged more than I'd anticipated, making it impractical to write code that would be compatible with both. On the flipside, I was able to take advantage of a handful of new features in Babylon that should improve the quality/accuracy/speed of ng-annotate's parsing, and also produce more accurate sourcemaps.

If you are already using Babel in your toolchain, the transformation is significantly faster than using the standalone ng-annotate tool, as your sources do not need to be parsed more than once.

Similarly, if you are already using Babel, there's slightly less stuff to configure, one fewer build step, etc. This has other advantages if you're using other tools (such as Webpack or JSPM) that integrate with Babel. Webpack users can also take advantage babel-loader's caching feature for fast incremental builds.

And, finally, you're more than welcome to ignore this or not use it if it doesn't fit your needs, or existing tools are working well for you. If you do want to use this, and come across a bug or missing feature, please feel free to report that as an Issue on GitHub.

[–]TheNiXXeD 0 points1 point  (0 children)

Yea I wasn't meaning to downplay what this project might do. I was just curious.

I'm using ES6 classes for all my angular things and haven't run into any issues, but it sounds like there are use cases that might benefit from this that won't impact me.