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: Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Hi again, > 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) Sorry, nevermind... I used the old "node-uglify" package instead of the newer "uglifyjs" package. After switching to the latter to provide the uglifyjs executable, I can process this file with no problems. So looks like we've sorted this out :) I don't assume uploading and updating with such changes would be acceptable in the soft freeze, would it? Cheers Sascha
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
Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Source: datatables.js Severity: normal 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. So far (up to 1.10.21) I managed to keep it building but we now have reached a point where some of the features used by upstream start to confuse the parser to the point of bailing out. This is a log of the build for the current latest upstream version: DataTables build (1.10.23) - branch: master JS JSHint not installed at /usr/bin/jshint - skipping JS compressing jquery.dataTables.js File size: 83936 JS compressing dataTables.bootstrap5.js File size: 2058 JS compressing dataTables.bootstrap4.js File size: 2098 JS compressing dataTables.bootstrap.js File size: 1979 JS compressing dataTables.bulma.js /tmp/jquery-datatables.2247.HN3wa/dataTables.bulma.js:170: ERROR - Parse error. missing ; before statement let nav = $(''); ^ [...] CSS CSS compressing dataTables.bootstrap5.css Error: Invalid CSS after "both": expected expression (e.g. 1px, bold), was ";" on line 7 of /build/datatables.js-1.10.23+dfsg/build/../built/css/dataTables.bootstrap5.css Use --trace for backtrace. File size: 0 I have seen #916145 and I am wondering what to do. Since I'm not a JS guy I can't say if (or for how long) we might be able to patch our way around this. Otherwise it looks like we're going to be stuck with 1.10.21 for the time being. Cheers Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916145