Comments (9)
This COULD be the problem: https://github.com/jashkenas/coffeescript/blob/81047d45ee823dbfd534b7aa518d800ae5cedd6c/src/coffee-script.coffee#L295
from node-source-map-support.
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.
from node-source-map-support.
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?)
from node-source-map-support.
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
from node-source-map-support.
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?
from node-source-map-support.
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.
from node-source-map-support.
@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.
from node-source-map-support.
At least there is a message, currently, either node-source-map
or coffee-script
traces stop working without any information.
from node-source-map-support.
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?
from node-source-map-support.
Related Issues (20)
- lib throws error with "Cannot read property 'isNative' of undefined" HOT 2
- Problems with Node 12 on Windows
- Removes error code from node errors HOT 2
- [meta] are tests running on CI? HOT 1
- Format the output so it can be clicked HOT 1
- decodeURI for chinese filename
- Using source map support removes details from some errors HOT 1
- TypeError: Cannot read property 'String' of undefined HOT 1
- Cannot find module when `import "source-map-support/register"` HOT 2
- Leaking event hooks which prevents process from exiting
- Error still show compiled code
- Error still show compiled code
- Source-map needs to be updated to 0.8.0-beta.0 HOT 1
- RangeError Maximum call stack size exceeded when testing Vue project HOT 1
- `lastIndexOf` in `sourcemap-register.js` causes Github to flag `Incorrect suffix check` HOT 4
- document that this package is no longer needed as of node 12.12.0
- WASM traces do not correspond to expected offsets HOT 2
- Provide esm version HOT 2
- Dependency of some other major open source projects
- Is there Micro Frontend support? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from node-source-map-support.