2.0.6 breaks the CLI!

[swashcap]

Bug

templatizer’s v2.0.6 contains a breaking change to the CLI functionality. Running the bin results in an error message:

$ node_modules/.bin/templatizer
: No such file or directory

This should output the usage info. CLI use with -d and -o flags produces the same error message.

Environment

• Templatizer: 2.0.6
• NPM: 4.5.0
• Node.js: 7.9.0
• OS: Ubuntu 14.04

Related: #107

[swashcap]

Similar response on OS X (10.12.4) with the same NPM && Node.js:

$ node_modules/.bin/templatizer
env: node\r: No such file or directory

Ruh roh! Seeing the same thing with Node.js@6.10.2 and npm@3.10.10.

Update:

Just confirmed 2.0.5’s CLI works fine. Unfortunately, there’s no templatizer code changes in the latest bump:

$ git diff v2.0.5..v2.0.6 --name-only
README.md
package.json

…which points to the bug coming from one of those updates. Might be nice to add some sort of CLI integration test to ensure this doesn’t happen again.

Update 2:

Cloned the repo. Running ./bin/cli totally works! This might be a gross npm thing.

Update 3:

npm link-ing w/ templatizer into my project fails to reproduce the bug. Gross!

[swashcap]

A little web search revealed nwutils/nw-builder#75, which indicates that a bad line ending on bin/cli’s shebang line messes up the env lookup. A little inspection reveals this somehow changed between 2.0.5 and 2.0.6:

$ npm i templatizer@2.0.6
# Install...
$ file node_modules/templatizer/bin/cli 
node_modules/templatizer/bin/cli: a /usr/bin/env node script text executable, ASCII text, with CRLF line terminators
$ npm i templatizer@2.0.5
# Install...
$ file node_modules/templatizer/bin/cli 
node_modules/templatizer/bin/cli: a /usr/bin/env node script text executable, ASCII text

Indeed, when I manually change the line endings in _node_modules/templatizer/bin/cli _ everything works. I assume git modifies line endings when cloning repositories, which is why I was unable to reproduce when I cloned this repository directly.

Now, how to fix the issue…

[HenrikJoreteg]

@swashcap thanks for digging into this, also @gdibble can you help out here? I've got my hands completely full right now.

[gdibble]

Thanks @swashcap.
Yep @HenrikJoreteg, planning to debug tonight when I'm available.

[HenrikJoreteg]

Thanks @gdibble. @swashcap in the meantime if you haven't already, you could certainly hardcode your app to 2.0.5 in your dependencies.

[gdibble]

There were a lot of dependencies updated before I bumped the version. While I have not seen this in my dev or production environments, I will test several OS's and plan to narrow down the module-update cause.

[swashcap]

@HenrikJoreteg Yeah, pinning to 2.0.5 seems like the best solution.

@gdibble I believe its last package publish occurred on a Windows machine, which modified the executable shebang line to:

- #!/usr/bin/env node\n
+ #!/usr/bin/env node\r\n

This change wouldn't be tracked by git because it figures out line endings for the OS automatically. The new line endings were pushed to npm with the 2.0.6 publish (that ASCII text, with CRLF line terminators above). Sounds like this is an ongoing npm issue (see npm/npm#13203). You’ll likely have to creating tooling (maybe fires a precommit bin test?) that ensures no bad line endings. The NWJS folks used an .editorconfig file to this end, but not every editor acknowledges it.

[gdibble]

@swashcap I was able to debug the issue and found the esprima@^3.0.0 module update is what broke us. I retested the CLI commands on Mac OS X and Windows 10 and no longer had the issue. Therefore I pushed a v2.0.7 to help. Let me know if you still have issues after the update. Thanks!