if require('coffee-script').register() is called after require('source-map-support').install() then source maps no longer function for exception traces

[breathe]

Here is the demo modified to demonstrate the issue:

require('source-map-support').install()
require("coffee-script").register()

foo = ->
  bar = -> throw new Error 'this is a demo'
  bar()
foo()

I encounter this problem because I have a module which is intended to 'require' some 'user' editable coffee-script configuration code -- if at any time after initializing source-map-support I later initialize the coffee-script support so that the node module loader can require .coffee files without pre-compiling, then the source-map-support exception rewriting behavior fails to function globally in my app ...

If I change the order the source-map-support and coffee-script modules are initialized in, then things work as expected:

require("coffee-script").register()
require('source-map-support').install()

foo = ->
  bar = -> throw new Error 'this is a demo'
  bar()
foo()

However this means I need to ensure that my process initializes the coffee-script module prior to initializing the source-map-support module -- even if enter my code through paths for which coffee-script support is not required at that time ... Particularly I encountered this issue when unit testing -- units tests give arbitrary entry points into my application's code where I wouldn't have thought I would need to initialize the coffee-script module unless/until its needed ... its a bit ugly that I must initialize coffee-script within the context of my unit tests so that I can enforce correct initialization order of the two modules ...

Is there a good workaround for this? The safest thing I can come up with is to add a new module which initializes both source-map-support and coffee-script in the correct order in my code -- and use that throughout my project's code anywhere I would've used require('source-map-support').install() ...

[sweetpi]

This COULD be the problem: https://github.com/jashkenas/coffeescript/blob/81047d45ee823dbfd534b7aa518d800ae5cedd6c/src/coffee-script.coffee#L295

[sweetpi]

And this fixes the problem for me:

var prepareStackTrace = Error.prepareStackTrace;
Error.__defineGetter__('prepareStackTrace', function(){
    return prepareStackTrace;
});

Error.__defineSetter__('prepareStackTrace', function(arg){
  if(arg && arg.toString().indexOf("getSourceMapping") != -1) {
    //ignore changes to prepareStackTrace from coffeescript
    return;
  }
  prepareStackTrace = arg;
});

A very dirty workarond, but I couldn't find a better solution.

[breathe]

That's pretty clever ... Seems pretty dirty indeed but there may not be any other way other than something along these lines ... What happens if other modules monkey-patch Error.prepareStackTrace ... Is it preferable to 'defeat' them with a mechanism like this? Since modifying the stacktrace involves modifying a global object -- it doesn't seem like there is any way that a more cooperative behavior among the various modules which do this could be built ... Using source maps seems like a 'more right way' to modify the stack trace than the behavior implemented by coffee-script (and perhaps other language specific modules?)

[julien-f]

Maybe this kind of behaviour should be prevented and an error logged.

Object.defineProperty(Error, 'prepareStackTrace', {
  enumerable: true,
  get: function () {
    return prepareStackTrace;
  },
  set: function () {
    var trace = console && (console.trace || console.log)
    if (!trace) return
    trace.call(console, 'an attempt to overwrite Error.prepareStackTrace has been prevented by source-map-support')
  }
})

Any comments? cc @evanw @joeyespo @marcominetti @mprobst

[joeyespo]

Interesting! Yeah, having it be noisy like what @julien-f has would be good so you can fix the problem early. Although outright preventing it from being set might be annoying if that's what you actually intended to do (ex: wrapping it one step further for additional debugging before the sourcemap transformation, a logger that then calls the underlying prepareStackTrace, etc).

So is there something deeper going on that requires a fix instead of here?

From what I understand, registering CoffeeScript allows you to require() coffeescript files and it'll run just like normal .js. Since there's a "build step" to these requires, the stack traces are no longer correct, so coffeescript also sets prepareStackTrace to correct this on-the-fly.

How does that play into this project? Is CoffeeScript being redundant by doing this translation? (I imagine the coffeescript source has a sourcemap that node-source-map-support uses, which is why switching the require order is working.) If that's the case, perhaps the correct solution be to warn here for guidance (with a way to silence it if this was intended), and to ultimately turn off the sourcemapping feature in CoffeeScript since we're handling that at a more general level.

What do you think?

[julien-f]

I don't think there are source maps when CoffeScript is hooked to require().

Maybe the ideal behaviour would be to intercept Error.prepareStackTrace() assignment and insert this module in between:

var prepare = prepareStackTrace
Object.setProperty(Error, 'prepareStackTrace', {
  get: function () {
    return prepare;
  },
  set: function (fn) {
    prepare = function (error, stack) {
      return fn(error, patchStack(stack))
  }
}

The problem I see with this solution is its complexity and the issue of how to deal with multiple override attempts.

I think the solution I gave earlier would be enough to start with because very simple and at least warns the user.

[joeyespo]

@julien-f Yeah, that'd be ideal. That would work best with other libraries that we aren't aware of right now. You're right, it does have a complexity cost. Luckily it's using a common pattern though.

Really, there's a complexity cost in both cases. The solution you proposed earlier still requires a dev to swap their dependencies in order to silence the warning (and perhaps spend time researching why exactly they had to do it). The actual complexity of fixing that depends on how their dependencies are wired together. It also has the cost of surprise when another library that uses prepareStackcTrace outright stops working.

[julien-f]

At least there is a message, currently, either node-source-map or coffee-script traces stop working without any information.

[joeyespo]

Ok, hmm. I mis-read your last solution, thinking the getter was calling the function it overrode. That doesn't seem possible to do with prepareStackTrace unfortunately. I guess it really is "winner takes all" here.

Ok, I'm on board with your first proposal. Can't think of anything more elegant at the moment.

As for @breathe's original problem, it seems like telling CoffeeScript not to automatically reformat stack traces is the real solution, since an external library (this one) is doing it instead. require("coffee-script").register() does other things that are useful, so you can't ignore calling that. Looks like there are already options to turn off the other features it provides. Perhaps CoffeeScript needs a new issue for an option to allow 3rd-party libraries to handle the sourcemap?