Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
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 signature.asc Description: signature
Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Hi, 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. [...] >> 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. > 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... Cheers Sascha
Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
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 = $(' aria-label="pagination">
> ^
> SyntaxError: Unexpected token: name (nav)
> at JS_Parse_Error.get (eval at
> (/usr/lib/nodejs/uglify-js/tools/node.js:33:1), :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
Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Hi Jonas,
great, thanks for your quick reply and the patch.
>> 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.
I also switched the old 'ruby-sass' dependency (which I understand is
deprecated) to sassc, which seems to work nicely.
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 = $('
^
SyntaxError: Unexpected token: name (nav)
at JS_Parse_Error.get (eval at
(/usr/lib/nodejs/uglify-js/tools/node.js:33:1), :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?
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 :)
Thanks and best wishes from the Debian Med sprint
Sascha
Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Quoting Sascha Steinbiss (2021-02-20 20:56:13) > 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. Patch attached. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private--- a/build/include.sh +++ b/build/include.sh @@ -124,14 +124,7 @@ cp $DIR/$FILE.js $TMPDIR/$FILE.js perl -i -0pe "s/^\/\*! (.*)$/\/** \@license \$1/s" $TMPDIR/$FILE.js - rm -f $TMPDIR/closure_error.log || true - java -jar $CLOSURE --charset 'utf-8' --js $TMPDIR/$FILE.js > $TMPDIR/$FILE.min.js 2> $TMPDIR/closure_error.log - - if [ -e $TMPDIR/closure_error.log ]; then - if [ -z "$LOG" -o "$LOG" = "on" ]; then -cat $TMPDIR/closure_error.log - fi - fi + uglifyjs $TMPDIR/$FILE.js > $TMPDIR/$FILE.min.js # And add the important comment back in perl -i -0pe "s/^\/\*/\/*!/s" $TMPDIR/$FILE.min.js signature.asc Description: signature
