Generally I would discourage adding more non-spec features to the V8's JS implementation. In the long run, these non-spec features cause compatibility problems, and often are a security nightmare. They also add unnecessary complexity to maintain. The reason we have not removed the prepareStackTrace API is because it was introduced more than 10 years ago, and so much existing code already relies on it. We would not have introduced it today. Providing this non-spec feature is already causing unnecessary memory leaks in some cases, and exposing script source as you suggest is not going to improve that.
I'm also skeptical about exposing the script ID. We only expose it via Chrome DevTools protocol, which is orthogonal to the JS-accessible stack trace API. +Shu-yu Guo <[email protected]> to maybe provide another perspective. I'd encourage you to use the Chrome DevTools protocol to achieve what you are trying to do. Cheers, Yang On Wed, Feb 17, 2021 at 5:42 AM Alex Kodat <[email protected]> wrote: > In managing a menagerie of scripts from various sources, I've found it > useful to enhance CallSite locally to have two additional functions > getScriptId and getScriptSource. The former provides a unique identifier > for the script that contains the code in the stack frame and the latter > access to the script source so one can say extract a sourceMappingUrl or > display more than one line around the point of error or show source lines > in a stack trace or whatever. While it's possible to maintain a table of > source ourselves (the scriptId would be helpful in managing such a table) > there's no great way of managing the lifespan of entries in the table so it > seems useful to be able to get access to the source via the Script object > which manages the lifespan of the source nicely. > > It was pretty trivial to add these so it doesn't seem like there's a major > downside, so does it seem reasonable to submit a CL for this? I'd offer to > fix up the doc at https://v8.dev/docs/stack-trace-api if it does, but, of > course, I don't have access. > > A bit more controversial, perhaps, would be that it seems it would be > useful to add a lazily instantiated metadata object on (internal) Script > objects. A CallSite could have a getScriptMetadata function to provide > access to this object. Similarly, maybe a GetScriptMetadata method for the > UnboundScript and maybe Module and Function classes would also provide > access to the object. The first request for the ScriptMetadata could create > an empty JS Object which could then be used by apps to store script > metadata such as, for example, a dereferenced sourceMappingURL. Again, we > could manage such metadata externally ourselves but it's a major pain > managing the lifespan of such metadata, especially as there's no way of > having a direct weak reference to the internal Script object -- the closest > we can get is a weak reference to the UnboundScript which is a proxy for > the SharedFunctionInfo which isn't quite right but might be workable. > > Does ScriptMetadata sound too crazy/special-purpose or should I try coding > it up and submitting a CL and let the reviewers judge if the pain justifies > the gain? > > Thanks > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/46c81d5a-e18e-43fe-b1ae-80002cbd56d8n%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/46c81d5a-e18e-43fe-b1ae-80002cbd56d8n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAFSTc_iyj-bjj9csbqKfz%2Bd_1wUfEfxSWk%2BUsYch%3DUeQ496atQ%40mail.gmail.com.
