Javascript error in precompiled asset: "Invalid or unexpected token" for code '#!/usr/bin/env node'

@jcspampinato

The shebang is required if the NodeJS script is required to be executed from the CLI, without using node. It functions much in the same way the shebang does for a bash script.

For example, let’s create two very basic NodeJS scripts:

demo01.js – w/o a shebang

console.log("Hello World");

demo02.js – w/ a shebang

#!/usr/bin/env node
console.log("Hello World");

If we run either demo01.js or demo02.js from the CLI using either:

node demo01.js

or

node demo02.js

… we should see “Hello World” as the output. So why use a shebang in demo02.js? Well, if it needs to be ran from the CLI, like a bash script, it’s required – additionally, execution permissions would be set to allow it to be executed in that manor.

For example, run chmod +x demo01.js and then chmod +x demo02.js. That’ll give the scripts their required permissions to execute as a script from the CLI, without node.

Now run (without using node):

./demo01.js

and

./demo02.js

demo01.js fails with:

./demo01.js: line 1: syntax error near unexpected token `"Hello World"'
./demo01.js: line 1: `console.log("Hello World");'

… while demo02.js results in the same “Hello World” that was expected. The reason for this is because that shebang equates to running node demo02.js.

…

So the question becomes does one or more of the scripts that you’re compiling require the ability to execute as essentially a shell script (like demo02.js), and if so, is pre-compiling preventing that?

Also, are you 100% sure that the environments are identical? Some use node, others use nodejs. If you have either or and the shebang references the one you don’t have an executable for, it’ll fail.

@jcspampinato

New reply due to response limits on the previous.

…

I would try to find the package that’s being compiled in which has the shebang, and then try to run without it to test whether it’s related to the problem, and thus, the error.

I mainly work with PHP/MySQL and Bash/Shell scripting, though similar issues exist when compiling NGINX and then using include to keep configuration files clean. You’ll often see an error that exists somewhere on the fully included source, but since you’re using includes, you have to manually open each file to find out where the issue may be (as the errors don’t correspond to included files).

That seems to be a similar case here. When you build all the assets together, it throws and error and fails, much like how NGINX does with includes at times, thus you have to do a lot of manual work to find out where the source of the issue really is.

So I’d try to find what has the shebang and compile without the package first. If it succeeds, you’ve found the issue. If it doesn’t there may be other issues that exist.

@jcspampinato

In most all scenarios, !#/usr/bin/env node should work just fine as it should find the executable. I say should – but that’s definitely not the case here.

It’s true that on older distros, node and nodejs were two entirely different packages. As of Ubuntu 16.04/16.10, the node package that was causing the confusion seems to have been pulled.

Differences in version can definitely cause some issues, I can confirm that from answering questions here in the community. What I might recommend doing would be to setup a test Droplet and use the repositories from NodeSource.

You can installer 4.x using:

curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -

apt-get install -y nodejs

You could then test the precompiled application against a 4.x release and see if it works. If it does, it may very well be a matter of versions (something was deprecated, removed, etc). If it doesn’t work, the issue may be between environments.

That’s what I’d do at least to test. I’d also take a look at the packages that are being installed during the compile. I’ve ran in to numerous abandoned packages and packages that hadn’t been updated for over a year with one question – they had no signs of coming back to update either.