[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-21 09:42:23)
> great, thanks for your quick reply and the patch.

You're quite welcome!


> >> 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.

What I meant by my remark above is that closure-compiler can do more 
advanced stuff as well - but since no custom arguments are provided (and 
I am unaware that it reads any project-specific configfile where some 
custom hints might be provided either), I would _guess_ that this projet 
would be equally served by using uglify-js.

Only way to know for sure is to test that resulting uglified code does 
what it is supposed do to.


> I also switched the old 'ruby-sass' dependency (which I understand is 
> deprecated) to sassc, which seems to work nicely.

Great!  I noticed that but forgot to mention it.


> However, I noticed that uglifyjs complains about the same line
> closure-compiler did:
> 
>       JS compressing dataTables.bulma.js
> Parse error at /tmp/jquery-datatables.23860.03SeC/dataTables.bulma.js:170,5
>         let nav = $('<nav class="pagination" role="navigation"
> aria-label="pagination">
>             ^
> SyntaxError: Unexpected token: name (nav)
>     at JS_Parse_Error.get (eval at <anonymous>
> (/usr/lib/nodejs/uglify-js/tools/node.js:33:1), <anonymous>:84:23)
>     at /usr/lib/nodejs/uglify-js/bin/uglifyjs:384:40
>     at time_it (/usr/lib/nodejs/uglify-js/bin/uglifyjs:620:15)
>     at /usr/lib/nodejs/uglify-js/bin/uglifyjs:345:9
>     at FSReqCallback.readFileAfterClose [as oncomplete]
> (internal/fs/read_file_context.js:63:3)
> 
> Changing the 'let' to a 'var' here fixes the error, but I fail to see
> why 'let' would be a problem here, syntactically. Any ideas?

"let" is a part of a more modern dialect of JavaScript.

You can replace uglify-js with uglifyjs.terser which supports newer 
JavaScript, but adjusting code to avoid that newer dialect is slightly 
safer because Terser is not maintained as well in Debian yet - see 
https://wiki.debian.org/Javascript/Nodejs#Minified_javascript for more 
info on that.


> 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 even think that switching from outdated closure-compiler to uglifyjs 
is a noble thing to do during soft-freeze - but that's your call!


 - 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/20210221/27aa6914/attachment.sig>