Isn't there ngmin for that?

[0x-r4bbit]

https://github.com/btford/ngmin

[olov]

Not the same, see https://groups.google.com/forum/#!topic/angular/X6JxHWGGoZk

[0x-r4bbit]

@olov A I see, so why not making ngmin better rather then introducing just another tool?

[olov]

@PascalPrecht the patch for that would be larger than the entire ng-annotate-main.js, and would turn ngmin into exactly ng-annotate. It's a different program with different goals, different analysis phase and different transformation phase.

[0x-r4bbit]

But wouldn't it be great if one tool can take care of all these scenarios
through option configuration or something like that? If a patch would turn
one module into another, but both are actually different, that definitely
cries for merging forces. I think we should ping @btford here to hear what
he thinks about that.

IMO it'd be cool if one module is able to solve these things rather than
installing two independent module, which are quite similar except for some
cases.

On Thu, Sep 5, 2013 at 2:24 PM, Olov Lassus notifications@github.comwrote:

@PascalPrecht https://github.com/PascalPrecht the patch for that would
be larger than the entire ng-annotate-main.js, and would turn ngmin into
exactly ng-annotate. It's a different program with different goals,
different analysis phase and different transformation phase.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-23863710
.

/pp

[olov]

Just for my understanding: What feature of ngmin do you like but don't find in ng-annotate? So far I know of only one apart from missing grunt plugin (coming), namely that ngmin tracks module name assignments - and I think that the alternative approach that I implemented in ng-annotate is mostly better and easier to understand. @btford I'd love to hear your thoughts on this (and props for ngmin by the way, I know that many are very happy with it).

@PascalPrecht do you propose to merge something other than the name, which would mean one tool completely replacing the other?

[olov]

(if so, I should probably mention that "ngmin" isn't a very descriptive name for what the ng-annotate tool/lib does)

[btford]

@olov A I see, so why not making ngmin better rather then introducing just another tool?

+1; If you have issues with my tool, we should discuss them. :)

[skuester]

I'll offer an agreement here as well. @olov , I'm glad you put in effort to solve this problem in an elegant way, and that you chose to share it with the community. These tools make en enormous difference in the maintainability and beauty of an angular codebase. Props to both you and @btford !

With that gratitude in mind, it truly is a better service to the community to contribute to existing tools, especially given how extremely close their use cases are - even if your contribution is almost a total rewrite. Both of you have made something awesome - I hope you're even better working together!

[alexandrosm]

I also agree that maybe people should try merging efforts on this, but I also agree with @olov on that the ng-annotate name is just more descriptive. ngmin doesn't actually min(ify) so it's a bit confusing. Also, I see @btford is extremely busy with lots of projects, and probably made ngmin because it needed to be made. In that case, and assuming ng-annotate doesn't have any obvious flaws, maybe it's a good idea to simply redirect the community to use ng-annotate instead?

[igorhart]

Good job @olov !
I am switching to ng-annotate :)

[olov]

@PascalPrecht @btford @skuester @alexandrosm @iskuhar
I just posted "The future of ngmin and ng-annotate" in btford/ngmin#93