I think this would belong in the "module meta" idea. It was detailed in more detail somewhere, but alluded to in whatwg/loader#38. @dherman might know more. The idea would be something like:

import { currentScript, url } from this module;

At other times people have suggested using metaproperties on import (currently the only metaproperty in the language is new.target; this would introduce a few more):

import.meta.currentScript; // or just import.currentScript?

Unfortunately the base extensibility hook here kind of needs a TC39 proposal for someone to champion, which is a whole process.

Is it correct to say that document.currentScript is not set, even for module scripts with no imports like:

<script type="module">
  document.currentScript == null;
</script>

Even if it were set in this case, I'd still want something similar to currentScript within imported modules. One use-case I have is to insert a template directly after the module script.

I like a variant of import.currentScript personally; I think introducing a special meta would invite questions like whether it is mutable or not. Maybe a better name came be thought of than currentScript (is it really current?) like ownerScript perhaps.

That's correct.

It should really be current; I don't see why it wouldn't be. We're still kind of waiting on TC39 to figure out the import metaproperty stuff though.

It's worth mentioning that we have a path forward here without waiting on TC39, which is to reserve a special module name. So then we'd do something like

import { currentScript, url } from "js:context";

import.currentScript sounds ideal here. With the dynamic import landed, perhaps a spec here can start to gain momentum. Landing features such as these soon will help significantly to avoid fragmentation of the adoption path features.

Note also feature detection here also seems tricky. I assume typeof import.currentScript wouldn't work, so it would just fall back to a syntax error if it isn't supported?

It's not directly related to this, I would like to note that I would like to have the similar thing in the module script in workers. See detailed thing why I would like to get it even in the workers. in tc39/proposal-dynamic-import#37.

I think we should spec something here soon that people are willing to ship. Node.js is also interested in getting agreement on this.

I'd like to propose

import { url, currentScript } from "js:context";

to get the current script URL (which could be that of a HTML file for inline scripts), and the current <script> element (which could be null if no <script> is currently executing).

How does that sound to implementers? /cc @whatwg/modules

"js:context" looks fine but we are open to bikeshedding from Node.js side.

Maybe it would be worth carving out the entire js: protocol-like-prefix for future stuff like this?

It effectively already is carved out, since fetching any URL that starts with js: will fail per today's specs.

Hate to tie this in to other bike-shedding, but it would be good if whatever naming scheme we choose matches TC39's naming scheme for internal modules (if they do arise).

That seems like such a hack. There is a proposal for global which is encountering some compatibility issue. Perhaps global should also live there?

@rniwa how is it a hack if it needs context to the environment it was invoked from (in this case, the location of import or import())?

I don't think global makes sense to put in the context-specific module, but people have proposed putting it in a built-in module before. I'd suggest discussing that in the global repo.

@rniwa, putting global aside, I can't tell if you think the import { url } from "js:context" proposal is good or not?

I don't like it. Conceptually, what you're trying to figure out the information about the current module, not about "js:context". Why is the url of "js:context" not "js:context"?

@rniwa you are grabbing an export of "js:context" named url, I don't understand why you would think it is the url of "js:context" given people can do things like export let url = "foo" in modules. Would a name different from url be sufficient?

"js:context" is a contextual module specifier. I can see the confusion because it looks like a URL and not a specifier. Given that it is a specifier distinct to the module loading it, what does it resolve to? What's the algorithm?

Let's pretend for a second that the algorithm resolves to "js:context:https://example.com/foo.js" where "https://example.com/foo.js" is the importing module. Would this mean that, I could do:

import { url, currentScript } from "js:context:https://example.com/bar.js" 

To grab another module's url/currentScript? Or would this be restricted?

Why can't we just know the current node the script is in? Especially if it's the top level script being included... certainly for imports of imported scripts the currentNode shouldn't apply...

'use import.meta' is only helpful if the source of document.currentScript was... but I'd like to know what the parent node is of the current script to know what part of the HTML DOM to search with something like

<html>
<head>
</head>
<body>

<div id="profileContainer"></div>

</body>

<script type="module">

const rootNode = document.currentScript.parentNode;
/* get something... */ rootNode.querySelector("#profileContainer") 


</script>
</html>

Otherwise I guess I can select all scripts and somehow figure out if one is 'me'?

@d3x0r you say "top-level script", but read this comment (and there's others in the thread above) as to why that's a fuzzy concept here—that top-level script is only evaluated once, no matter how many times you include it:

<script type="module" src="entrypoint.js"></script>
<script type="module" src="entrypoint.js"></script>
<script type="module"> import './entrypoint.js'; </script>

So what's the currentScript?

Yes, for the inline case I guess there'll only ever be one script. But at that point it seems like you already know "where you are". Just my 2c.

the first two are their own tag; the third, entrypoint.js doesn't get the script...

https://github.com/d3x0r/sack.vfs/tree/master/tests/objstore/userDb/ui/profile Is what I was playing with.

The popup library fillFormURL(popup,url) function does a fetch of the URL, and then sets the .innerHTML of a div within the popup (which are approx. 5 nested frames), The script tags that are found are replaced with script tags that are the same, but will actually end up loading.

The index.html will eventually be some other service, which just includes "login.js" sort of script, and provide a 'login-with' sort of functionality... so there's no telling what the outside framing will really be.

certainly I can hear people saying 'don't do that' without a single answer to 'why' so... religious opinions aside... that's what I was attempting to do.

As a workaround <script> tags with textContent can have information prepended to them on the replace function to add a unique ID for the script itself, which allows scripts in the HTML to find their relative root... but cannot from any .js file itself; as would be loaded by a src attribute.

the first two are their own tag; the third, entrypoint.js doesn't get the script...

I'm not sure what do you mean there. In the example given, entrypoint.js will execute exactly once. Please go read the whole issue, especially #1013 (comment) and the subsequent discussion. It's not productive to keep repeating the same discussion over and over.

I would also like a way to get the ShadowRoot object from with in the shadow DOM's own scripts. Wasn't this the whole point of encapsulation? Am I missing something? I honestly don't know.

@whaaaley and others, maybe this will help you out.

I can't remember where/when I came up with this method but it definitely belongs in this thread :

connectedCallback() {
  const scopedEval = (script) => Function(script).bind(this)();
  const scripts = this.shadowRoot.querySelectorAll('script');
  scripts.forEach(s => scopedEval(s.innerHTML));
}

This runs any script elements in the shadowRoot of a custom element with the host object as the scope. Here's a more thorough example using a closed shadowRoot.

@besworks the number of reasons that’s unsound are too many to enumerate. it may suit a particular case but should not be promoted as a general solution.

@bathos, obviously the correct solution in most cases would be to simply not use script tags inside your shadow dom at all but for those few cases that it's necessary (like importing a clunky old library) this trick is like magic. The snippet above is clearly a simplified demonstration. As you can see in the jsfiddle I used #private class properties and methods to make sure this cannot be executed from outside the component. It also works with a closed shadow root so there's no worry about script injection that way. Can you think of any other ways this could be abused?

The reason I want this is because I've been experimenting with different ways to load random components built with modern frameworks into shadow roots. Assuming you're using some kind of virtual dom framework in the parent application you could do something like this with a global.

function React () {
  // eslint-disable-next-line no-return-assign
  return <ShadowRoot id='react'>
    {window._reactRef = <div id='root'></div>}
    <script type='module'>
      {`
        import 'https://unpkg.com/[email protected]/umd/react.production.min.js'
        import 'https://unpkg.com/[email protected]/umd/react-dom.production.min.js'

        const root = ReactDOM.createRoot(window._reactRef.node)

        root.render(
          React.createElement(React.StrictMode, {},
            React.createElement('div', {}, 'hello from react')
          )
        )
      `}
    </script>
  </ShadowRoot>
}

I started to wonder though. Why is this inside of script modules undefined? But this usually refers to window. Would it not make way more sense for this to return some type of object pertaining to the module, and if that script is loaded within a shadowRoot, then it would have a property like this.shadowRootDocument??? Or even just this.document for compatibility with old libraries?

I mean don't mind me. I don't know much about the details of the module system, but ergonomics wise, and for symmetry with how you'd do this without shadowDOM, this makes sense to me over something to do with the import statement. Maybe this is naive, but to me it sounds to me like import.meta is just a weird syntax to make up for the lack of this inside scoped contexts like a shadowDOM. Maybe someone can educate me on why this is the case. I'd actually like to know.

@whaaaley, I've done some experimenting with various ways to inject scripts into shadowRoots as well and just posted a very thorough overview of this problem in WICG/webcomponents#717 (comment)

I believe this discussion more appropriately belongs in that thread, even though it's closed. The document.currentScript issue discussed here seems related but is actually a byproduct of what you're describing, which is ultimately an issue with how the evaluated scripts are scoped.

but to me it sounds to me like import.meta is just a weird syntax to make up for the lack of this inside scoped contexts like a shadowDOM.

Kind've, basically this was used in all sorts of ways in classic scripts, which is why strict module and modules narrowed their uses to be more the usual intent of this (i.e. the object for methods). import.meta was added as a way to more clearly associate something per-module rather than overloading this to have yet another special-cased behaviour.

The advantage of having a separate thing, is that import.meta can even be used inside methods that might have a different this (i.e. in classes).

It would be plausible to add import.meta.script for inline scripts, but not for src scripts as in general many <script src= could point to the same module (or the module might've even been loaded with import(...)). (And exposing the first script, would lead to very race-condition prone code).

If HTML modules ever get implemented, there would be a similar inline-only script feature (import.meta.document) that is pretty similar, so it wouldn't be particularly strange to expose a import.meta.scriptElement for inline scripts.

import.meta.scriptElement sounds reasonable to me.

I'm down for any solution that will give me a path to get access to the shadow root document. Is there any chance we can get access to the current document in import.meta as well? It seems to me the primary reason for wanting scriptElement is just so we can traverse upwards to the current document because that's how it used to be done in v0 of shadow dom api... So why not just add import.meta.currentDocument which refers to the document the script is loaded in and avoid the traversal step all together? Then there's also no confusion with which script element to return in the case of multiple script imports. Let the developers query it themselves once they have the current document.

@besworks I read your post in the other thread. I can see both ideas being correct. However, I think the path of least resistance is probably slapping more stuff onto import.meta. Though I did really like your idea of configuring how shadowRoot scripts work with attachShadow options. That should definitely be expanded on as well.

I agree that import.meta.currentDocument would be a good property to have. As long as it actually returned the shadowRoot and not the document that the shadowRoot is connected to. I think that import.meta.scriptElement would definitely be useful too. Then we could do import.meta.scriptElement.ownerDocument or access siblings, etc. These would be great for many use cases, but the way scripts in a shadowRoot are currently evaluated, their ownerDocument is actually the host document. So implementing either of these properties alone is not enough. I believe more work needs to be done to make the ShadowRoot interface behave more like a wrapper for the Document interface instead of just the DocumentFragment interface which it currently extends.

@besworks The host document or the host node? 🤔 There's some stuff I could do with a host node to get some desired behavior at least. But not with a host document.

Here's an example of what I mean :

<div id="host"></div>
<script type="module">
  let host = document.querySelector('#host');
  let shadow = host.attachShadow({ mode:'closed' });
  let script = document.createElement('script');
  script.textContent = `console.log(document.querySelector('#host'))`;
  shadow.append(script); console.log(script.ownerDocument);
</script>

You might expect that after the script was appended to the shadowRoot it would no longer be part of the host document. But this not the case. The shadowRoot is not actually a separate Document but rather a DocumentFragment contained as a property of the host element. We have full access to the host document scope and every element in it but no access to the scope the script is actually connected to, unless you drill down into it from outside, which you can't do if you use a closed shadowRoot.

So, even if you were to access the hypothetical import.meta.currentDocument from inside a shadowRoot, you would still get a reference to the document that contains your component and not the shadowRoot like you want unless special handling was put in place for this scenario. This may still prove to be the best route and less complex than messing with the ShadowRoot interface, though I do still believe there is room for improvement there.

One technique I experimented with involved building a virtual document to process my scripts in with the intention of appending the output to the shadowRoot afterwards. This didn't work out because according to section 8.1.3.4 of the spec

Scripting is disabled for a node when its node document browsing context is null.

Which is exactly the case when using document.implementation.createHTMLDocument() and DOMParser() and the same with new Document() ...

So, with all that in mind, the best workaround I've come up with, is the spooky dark magic method that always seems to ruffle everyone's feathers. But it gets the job done and, if used responsibly, overcomes all of these problems.

It seems to me the primary reason for wanting scriptElement is just so we can traverse upwards

I for one want to scriptElement.getAttribute(…).

not sure if it's entirely related, but adding a use case here anyway.

i'm trying to write some isolated code examples for a documentation site. i wanted to use declarative shadow dom for this, so styles and IDs do not leak out. but i also wanted to include some scripts as part of demos e.g.

<div class="example">
  <template shadowrootmode="open">
    <style>
      button {
        color: red;
      }
    </style>
    <button>click me</button>
    <script>
      // how to select the button?
    </script>
  </template>
</div>

e.g. here i wanted to log a click on the button. but there's no easy way to get a reference to the button which doesn't completely detract from the example itself. it would be nice if there were something like currentDocument, though i am not precious about any particular solution.

One of my favourite patterns (because its very robust) is to do the following:

<script data-foo="someOptionAddedByServerSideTemplatingEngine">
(function(options){
  console.log(options.foo);
})(document.currentScript.dataset);
</script>

I know - this seems complicated but - trust me - i have use-cases, where this is the most robust way (dynamic generation of script tags, template engines, escaping, ide code handling, lsp support, and so on).

But with this pattern i am stuck to regular script types. I would really like to convert this to

<script type="module" data-foo="someOptionAddedByServerSideTemplatingEngine">
const options = import.meta.currentScript.dataset;
console.log(options);
</script>

Would having import.meta.scriptElement only defined for inline module scripts be a viable solution?

It seems to me that "what script element caused the loading of this module?" and/or "what script elements are connected to this module in the import graph?" are more complex and less useful questions to ask compared to "what script element contains this code?"

Conceptually, I think of <script type="module" src="foo.js"> as importing a module defined elsewhere, whereas <script type="module">console.log("hello, world")</script> defines a module in the current document. The definition for the former lives at a URL that can be introspected with import.meta.url. The definition for the latter lives in a HTMLScriptElement that can be introspected with import.meta.scriptElement.

Does that make sense?

Would having import.meta.scriptElement only defined for inline module scripts be a viable solution?

I think this makes some sense on the surface, but there's a big hazard with things changing so much depending on whether the script is inline. Tools may change a script from inline to external or vice-versa and break things.

You would get roughly the same effect if import.meta.scriptElement was defined only for the module directly imported by a script tag, and maybe only during the top-level evaluation of the module. Then if a script were made external, it would still work, since presumably it's also only imported once.

As @rniwa has pointed out, though, there isn't really a well-defined answer to "what script tag imported this module?" (nor, even, for "what module imported this module?") because a module can be imported from a bunch of different places at different times. That's why I think focusing on where the module is defined is a more well-founded approach.

The hazard of module behaviour changing depending on whether the script is inline applies to import.meta.url as well... I think that's just an unavoidable consequence of this kind of reflection. Presumably bundlers have to emulate import.meta.url too, right?

For external modules, this pattern might be reasonable:

<script type="module">
import something from 'module.js'
something(import.meta.scriptElement)
</script>

The 1:N definition:import relationship has to get dealt with somewhere, but this way your something function can have whatever application-level semantics make sense.

The only other answer I can think of would be some kind of import hook that a module could use to know when it's been imported and what by? That seems like a whole can of worms though...

I could imagine a world in which the script tag has a getter for the exports of the imported module and we could use

<script type="module" src="http://example.net/opaque.js" onload="
  const scriptTag = this;
  scriptTag.getExport('default').then(m => m.install(scriptTag));
">/* … arbitrary data, e.g. config settings … */</script>

Maybe we can even convince browsers to support a run shorthand for a method name exposed on the default export, so we could shorten the above to:

<script type="module" src="http://example.net/opaque.js" run="install">/* …data… */</script>

Or when it's empty, it means that the default export is expected to be the entrypoint function, i.e.

<script type="module" src="http://example.net/opaque.js" run>/* …data… */</script>

would be the same as

<script type="module" src="http://example.net/opaque.js" onload="
  const scriptTag = this;
  scriptTag.getExport('default').then(m => m(scriptTag));
">/* …data… */</script>

I think the four bytes " run" could become one of webdev's most beloved HTML additions. (In before "you can even omit the space!")