[Pkg-javascript-devel] Bug#983190: Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler

[Jonas Smedegaard]

Quoting Sascha Steinbiss (2021-02-23 12:53:40)
> >>>> If you are wondering why there haven't been any updates lately, I 
> >>>> am sad to announce that current versions of datatables.js does 
> >>>> not build anymore with the old version of closure-compiler in 
> >>>> Debian.
> >>>
> >>> Looks like it does not really need to use closure-compiler, so I 
> >>> would suggest to instead use uglifyjs.
> >>
> >> I see. Do you think that would be safe to use as a replacement? 
> >> Both would generate functionally equivalent minified JS, right? 
> >> Ignoring slight size differences, of course -- the uglifyjs output 
> >> is ~50KB larger than the closure-compiler one in a previous 
> >> version.
> > 
> > In theory closure-compiler and uglify-js perform same type of task, 
> > yes.
> 
> [...]
> 
> > Only way to know for sure is to test that resulting uglified code 
> > does what it is supposed do to.
> 
> Difficult, because the tool I initially needed it as a dependency for 
> (aegean) does not use the minified version. But I can tweak the output 
> to use that and see if the behaviour breaks -- it doesn't seem to 
> really use much of the datatables functionality with the non-minified 
> version anyway. So if it breaks in subtle ways I won't catch it.

Sounds like you don't know if your use of ancient closure-compiler is 
broken either.

I recommend to use uglify-js even without being certain - better to be 
uncertain with a currently maintained general-purpose tool than being 
uncertain with an ancient general-purpose tool.

(i.e. only if upstream had used custom advanced options for 
closure-compiler would I worry about tool-related breakage)


> [...]
> >> So I think it would be quite doable to scrap closure-compiler here 
> >> and switch to uglifyjs and sassc if you don't see any obvious 
> >> reasons to abandon upstream's choice of tools. Given my limited 
> >> expertise in JS best practices I would be happy to trust your 
> >> advice :)
> > 
> > I sure think uglifyjs is safer to use than *outdated* 
> > closure-compiler.  Just make sure to test the result as best you 
> > can.
> 
> I wonder if there is anything that would allow me to easily test the 
> behaviour without really knowing much about what is possible with 
> datatables. I'll look at the other reverse deps when I find the time.

If you _really_ want to be more conservative (which I think is 
unnecessary, but your call) then I recommend to *not* minify the code at 
all - i.e. replace with symlinks to the non-minified files.

Better serve bloated but correct code than tiny but unreliable code.  
Vaguely comparable to compiling C code with "-O1": Hurts performance 
instead of stability.


> > I even think that switching from outdated closure-compiler to 
> > uglifyjs is a noble thing to do during soft-freeze - but that's your 
> > call!
> 
> I think I'd rather stick with a not-so-fresh version that is built 
> traditionally than shipping one I have not tested and does not use 
> upstream's recommended tools. I'd prefer to postpone this till the 
> next release. Unless there are volunteers...

Please note that you most likely *already* don't use upstream's 
recommended tools: Do they recommend _ancient_ closure-copiler???


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20210223/9668b269/attachment.sig>