Make the REPL *CLI* use the global context so as to (a) be consistent
with the `node` REPL CLI and, therefore, (b) make packages that modify
native prototypes (such as 'colors' and 'sugar') work as expected.
Note that, by contrast, programmatic use (`require 'repl'`) will
continue to default to a NON-global context - again, consistent with
node's behavior.
Note that, at least for now, CoffeeScript's own REPL *CLI* still uses a
non-global context, rendering modules such as `color`, which attempt to
modify the prototypes of JavaScript primitives, ineffective. By
contrast, node's own CLI does use the global context.
This solves two potential problems when it comes to forking:
1) Forking will now work correctly even when `coffee` is not installed
globally.
2) Forking when using a locally installed version of `coffee` will fork
using that version, and not fallback to a globally installed version.
Fixes#2957
This makes the "stack" property more useful when it's shown on other Node.js applications that compile CoffeeScript (e.g. testing libraries) and should fix#3023. A minimal example:
$ node -e 'require("coffee-script").compile("class class")'
/usr/lib/node_modules/coffee-script/lib/coffee-script/coffee-script.js:41
throw err;
^
[stdin]:1:7: error: unexpected CLASS
class class
^^^^^
Instead of throwing the syntax errors with their source file location and needing to then catch them and call a `prettyErrorMessage` function in order to get the formatted error message, now syntax errors know how to pretty-print themselves (their `toString` method gets overridden).
An intermediate `catch` & re-`throw` is needed at the level of `CoffeeScript.compile` and friends. But the benefit of this approach is that now libraries that use the `CoffeeScript` object directly don't need to bother catching the possible compilation errors and calling a special function in order to get the nice error messages; they can just print the error itself (or let it bubble up) and the error will know how to pretty-print itself.
In #3031, an extensions variable was introduced with file-level scope
that defined the filetypes that CoffeeScript can compile. However, the
Module::load patching calls findExtension() which uses a local variable
called "extensions", which was overriding the outer level one and
causing getSourceMap() to fail.
Example: if compilation invoked like this: 'coffee -o ../lib/ -cw ./', then
Source file: ./OutputFolder/file.coffee, compiled output: ./../lib/tputFolder/
The code only expected '.' to mark the local folder. However, './' is equally valid.
