ChakraCore is the core part of the Chakra Javascript engine that powers Microsoft Edge
@liminzhu has put up a statement about the future of ChakraCore in #5865 @Mouvedia @CatCatCatDog @fatcerberus
I'm fetching from https://aka.ms/chakracore/cc_linux_x64_1_11_4 for now... so far it seems to be stable
i.e. you hover over a line of JS, it highlights the bytecode generated for that line in the dump
So I guess in my reality my requirements are:
- Ability to get a bytecode dump via the API
- Ability to map generated bytecode instructions to source lines
I don't believe that we expose any of that to js-land debuggers (including via our debugging API). We have internal native debugging tools which can do that, and the bytecode instruction -> source line functionality is built in to the bytecode, but I don't think we surface that via JSRT at all
It's not obvious to me what exactly that would mean. One possible hackish solution would be to do
(new Error()).stack and see what that gives you. In node-chakracore we had some small amount of support for inspecting error.stack without just getting back an opaque string, but I forget exactly how we did that right now
(it was all via the chakrashim host layer, so any host can do it)
What I’m trying to do is support relative paths in
require() called from an ES module
In CommonJS that works because each module gets its own copy of require, but for ESM I’d need to know the URI of the module that called require
Pulling the stack trace off an Error object was my first idea too, but wondered if there was a “sanctioned” solution
There's also weirdness with this whole idea, like e.g. what would
["a.js", "b.js"].map(require) do? What is the "caller" of require there?
Intuitively, I would want that resolved against the module calling .map
And even if in this case we skip over internal library frames, the same issue could come up from shims or other things providing non-default library functionality
From an engine perspective, it's basically impossible to tell them apart I think, so the best way in my mind is to be specific and essentially bind the function to a particular context, e.g. specialize it for a given module
And yeah, I think the simplest way to do that is to do something like the commonjs approach where you inject a bit of code at the start
If you jam it all on one line, then it wouldn't impact user code much at all
But if they do put things on the first line (especially if it's minified) then that could be a pain
But as @MSLaguana points out, higher-order functions complicate matters
The error object is returned via
result IIRC
If you string coerce it you only get the error message but you can read properties off it instead
It’s the same thing you would get back in JS for
try { eval(invalid_code); } catch(err) { ... }
so I'm dense, or out of my depth here... I get what I think is the object you are talking about using JsGetAndClearException(obj). Using JsConvertValueToString/JsStringToPointer, I get the string I referred to above. So then I try to get the line property from it - using JsGetPropertyIdFromName and then JsGetProperty - and I get undefined for the value of the property.
Assuming you're using chakracore I generally would reccomend avoiding the APIs in ChakraCommonWindows.h; stick to the APIs in ChakraCommon.h and ChakraCore.h