Question

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

My site runs fine locally in development. However, deployed on digital ocean in the Ubuntu 16.04 environment, it breaks because the so-called ‘shebang’ line above, which is not in any of my original js code, nor directly in any of the js libraries I have incorporated into my project, errors in my browser console. The ‘’#!/usr/bin/env node’ line is line #29589 in a precompiled asset.

My assets were precompiled locally an are included in my repo. I removed them all from my Production host and ran rake assets:precompile there, but still get the error. I manually removed the line from the precompiled file in question, restarted unicorn and nginx, yet still get the error, which I completely don’t understand.

This isn’t my code, but it’s somehow breaking my production site for unknown reasons, and I doubt it should be.

Can anyone explain to me:

  1. Is the line ‘#!/usr/bin/env node’ supposed to be in my precompiled asset or not.
  2. If it is, why it breaks my production site, or, if it ain’t, why it’s there and how to make it not appear in my precompiled asset.
  3. what am I doing wrong in troubleshooting that manually deleting the offending line, then clearing my local cache and manually restarting unicorn and nginx on my droplet STILL results in the removed line appearing and breaking my site in my local broswer?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

@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.