You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But assuming the browser will parse it, could it not expose the parsed object in some way?
I know the intention is to not allow for adding metadata, but scheming developers like me will still probably be quite tempted to add metadata (for example, appending #myMetaInfo= after the path to a js file).
Any harm done in exposing the parsed object? That could reduce cpu a bit.
The text was updated successfully, but these errors were encountered:
Unless it was a getter that returned a new object every time, then I’d wonder what happens if you mutate that object - and if the object is mutable for future accesses, then the only robust thing is to manually parse anyways, so the object access seems to lose its value :-/
Yeah, I think we not rush into a solution here, to leave open the door for a future, mutable-in-a-controlled-way, "import map object model" API that allows runtime changes to import mapping.
For example, such an API would probably be a per-realm representation of the merged import maps, and not per-script element. So we wouldn't want to provide the functionality equivalent to the OP since that wouldn't mesh well with the future work.
It would only take a single line of code for application logic to parse the JSON string of the importmap:
But assuming the browser will parse it, could it not expose the parsed object in some way?
I know the intention is to not allow for adding metadata, but scheming developers like me will still probably be quite tempted to add metadata (for example, appending #myMetaInfo= after the path to a js file).
Any harm done in exposing the parsed object? That could reduce cpu a bit.
The text was updated successfully, but these errors were encountered: