when running _coffee <filename.coffee> a fatal error occurs

[mreinstein]

dbits@bytesamurai:/mnt/wwwroot/Exceptions/server$ _coffee exceptions_srv.coffee Failed to find CoffeeScript from /mnt/wwwroot/Exceptions/server Error: Failed to find CoffeeScript from /mnt/wwwroot/Exceptions/server at Object.load (/usr/lib/node_modules/streamline/lib/util/coffee-loader.js:13:13) at Object.run (/usr/lib/node_modules/streamline/lib/compiler/underscored.js:65:54) at _run (/usr/lib/node_modules/streamline/lib/compiler/command.js:77:29) at Object.run (/usr/lib/node_modules/streamline/lib/compiler/command.js:107:3) at Object. (/usr/lib/node_modules/streamline/bin/_coffee:7:14) at Module._compile (module.js:446:26) at Object..js (module.js:464:10) at Module.load (module.js:353:31) at Function._load (module.js:311:12) at Array.0 (module.js:484:10)

I've scoured the internet looking for answers as to why this won't work, but haven't found anything. This used to work, but upon running npm update -g and getting updated code, this error seems to be occuring now. Any ideas why?

[bigeasy]

Programs like Perl can be invoked...

#!/usr/bin/perl -w -T
print "Hello, World!\n"

...because Perl is called directly and it knows that it's first parameter may be a hodgepodge of many parameters, so it parses it. env on OS X does as perl does. Other env do not.

[bigeasy]

I think that this fix is worth it. It makes things work "out of the box" in situations where it did not before.

I'd look far more carefully at the CoffeeScript compiler and how it works. It would be best if _coffee -c accepted the same arguments as coffee -c and behaved in the same way. I don't know how this is going to effect _coffee in the shebang line, because now _coffee has a different search path strategy from coffee.

If there are no differences from the Node.js search algorithm, then there is no documentation burden. You don't have to document how the search algorithm in Streamline.js is different and why.

This isn't fancy require logic — it's really as simple as "require relative to the code" just like both Streamline and CoffeeScript already do for regular dependencies.

From what I saw, CoffeeScript only updates the module dependency of the main module for a script run from coffee. It does not otherwise interfere with require and behaves in the same way as it would in Node.js. It doesn't update the search path at all during compilation.

If the only problem with building on NPM is a search path, have you tired doing something like:

{ "scripts":
  { "build": "NODE_PATH=./../my/relative/path/node_modules _coffee -c lib/" }
}

Maybe that won't work on Windows. I don't know.

If building on NPM is desirable, can't there be a build-streamline-on-npm project to which we can offload the complexity and NPM awareness? To say that "out of the box", the _coffee compiler can build your code on NPM, you've just made the Streamline.js dependent on NPM. Changes to NPM will affect Streamline.js.

Also, if you're going to use Streamline.js to compile your source on NPM, to my mind, you would _of course_ explicitly preinstall it because it is not a runtime dependency, but unfortunately it is because you have to install all of Streamline.js to require the runtime. This strikes me as less of a module require path problem, more of a problem of Streamline.js module organization.

Streamline.js is monolithic. I'd like to see it broken up into smaller packages. Adding stuff like this to Streamline.js makes it more monolithic. If all sorts of stuff is going to work "out of the box", that is going be one awfully big box.

Maybe monolithic is desirable. It has it's benefits. Modularity has it's problems.