Nativescript fail in static bindings generator parser and my "solution" - tremho/thunderbolt-common GitHub Wiki

Trying to run 'ns run android' I got the following error

Error executing Static Binding Generator: Couldn't find '/Users/sohmert/tbd/nativescript/tbTest/platforms/android/build-tools/sbg-bindings.txt' bindings input file. Most probably there's an error in the JS Parser execution. You can run JS Parser with verbose logging by executing "node '<path to my project>/platforms/android/build-tools/jsparser/js_parser.js' enableErrorLogging".

and so running their verbose command as suggested gives me something like this:

Error processing '<path to my project>/platforms/android/app/src/main/assets/app/vendor.js:' SyntaxError: Unexpected token, expected ( (117451:695)

of course, vendor.js is a gargantuan file, consisting of all the node_module code of the project, so after a SO query for how to do so, I employed the tools of sed and grep and with that was able to tease out the offending code and the lines around it in order to find which node module was responsible. Sometimes the distribution code of the module is minified and that makes the detective work all the harder, but sometimes it's just a matter of finding the right number of lines before the offending problem to find a function name or something definitive that can be searched for.

For example, one such incidence:

node '<path to my project>/platforms/android/build-tools/jsparser/js_parser.js' enableErrorLogging

	Error processing '<path to my project>/platforms/android/app/src/main/assets/app/vendor.js:' SyntaxError: Unexpected token, expected ( (125486:10)

 sed -n '125480,125486p;125487q' //Users/sohmert/tbd/nativescript/tbTest/platforms/android/app/src/main/assets/app/vendor.js
})

function emptyDirSync (dir) {
  let items
  try {
    items = fs.readdirSync(dir)
  } catch {

It's always the catch statement that causes the problem.

It would appear that the js_parser.js code of the Static Binding Generator expects there to be an exception identifier argument in the catch statement because it is expecting a '('. But this is not a correct expectation, as noted here.

So the real bug -- it would seem is in this code and not in the many modules. That makes sense. Nevertheless, I did things the hard way and tracked down all of the offending issues one at a time through multiple error runs and subsequent sed and grep and editing fun until all the naked catch { statements were replaced with catch(e) {, and after all of that everything runs.

However, it will all go away again the next time I do any form of npm install, so it's not a great fix.

For the record: Here are the files I changed

  • node_modules/jest-worker/build/WorkerPool.js
  • node_modules/jest-worker/build/workers/messageParent.js
  • node_modules/fs-extra/lib/ensure/file.js
  • node_modules/fs-extra/lib/ensure/symlink-type.js
  • node_modules/fs-extra/lib/remove/rimraf.js
  • node_modules/fs-extra/lib/empty/index.js
  • node_modules/fs-extra/lib/mkdirs/make-dir.js
  • node_modules/es-module-lexer/dist/lexer.cjs
  • node_modules/es-module-lexer/dist/lexer.js
  • node_modules/globby/index.js

fixing the parser instead

That's a non-starter at the moment because the file itself is highly minified and complex enough not to try to defang in a minified state.

Even if I did fix it here, it's as ephemeral as tweaking the module code is because it will go away when a new platform is generated.

The only right thing to do is to find this in its repository, fix it there and submit a PR.

But today, I'm just trying to get some work done on my own project.

UPDATE:

I finally did find where this lives in repository, here. Not sure what good that does me. I suppose I could bring this down and play with it and see if I can hack in a fix to post as PR

But it actually looks like they are using the Babylon parser, so it may be an upstream issue there.

Argh! Final update! It's FAKE NEWS!

Shit. It turns out the problem was the ns create, etc done by the cli script was still using tns instead of ns and that was enough to screw the pooch. After fixing that, it all works as expected again.