search

documentcloud / jammit

Industrial Strength Asset Packaging for Rails
http://documentcloud.github.com/jammit/
MIT License
1.16k stars 197 forks source link

Remove jsmin from dependencies #262

Open balasankarc opened 9 years ago

balasankarc commented 9 years ago

It seems jsmin (and cssmin) are no longer maintained. So, should jsmin be used in the project? I am currently packaging jammit for Debian. But, It can't be completed because of the json-evil-license under which jsmin is released. And, it won't be changed (since it is unmaintained). This directly affects the inclusion of jammit in Debian as jsmin is a runtime dependency for jammit. Moreover, since jsmin is unmaintained, any bugs that may come in the future will not be rectified.

I saw that the last version of jammit depended only on yui-compressor. It is still maintained. It seems to be a better choice now.

jashkenas commented 9 years ago
  1. Jammit probably shouldn't be packaged for Debian. It belongs in Rubygems.
  2. We generally shouldn't be changing dependencies just because someone doesn't like the license. JSmin is released under a perfectly fine license, and if that stops you from using it, then that's your cross to bear — don't hassle us about it.

But! There are better options out there today — that didn't exist when Jammit was first written — that do a better job than JSmin does. It would be great to switch over to Uglify.

balasankarc commented 9 years ago
  1. I beleive that, by packaging it to Debian, more people can access jammit. Also, it helps in bringing many other packages to debian of which Jammit is a dependency of. I agree Rubygems is a great place to get gems, but packaging it to Debian brings no loss to anyone. :)
  2. I am not the right person to talk about the license constraints of Debian. Leaving that, we still have the problem of JSmin being unmaintained. That means, future bugs that may occur will not be rectified.

Sorry for the unintended hassle. And thanks for considering my suggestion. :)