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.
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.
(My apologies: In the previous commit I accidentally made `useGlobal:
yes` the default for _programmatic_ use also, but the intent was to
only do it for the stand-alone *CLI*.)
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.
This will make packages that modify prototypes - e.g. 'colors', 'sugar'
- work as expected.
To verify that the `node` REPL uses the global context, execute `global
=== module.exports.repl.context`.
Note: Tests pass, except `cluster.coffee`, which, however, failed even
before these modifications.
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.
