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
signature.asc
Description: signature
