Spec: Would `!!import.meta ? 'module' : 'not'` be a reasonable ask?

[SMotaal]

I'm think we all must have considered this at some point, but cannot recall.

Q: Is there a safe way for code to test if it is module or not (ie not early/parse error)?

This code would target runtimes supporting import(…) globally, irrespective of semantics, and so my thinking was a clean nice-to-have here could be !!import.meta ? 'module' : 'not' which should not be too much to ask for… thoughts?

---

Possibly Related Discussions

• import.meta.main in nodejs/node#49440

[SMotaal]

Code that is wrapped also can’t know if it’s transformed - which means import.meta, or any syntax, would be unreliable anyways.

@ljharb sure, possibly, but a runtime taking steps towards conformance and the fact there are potentially bugs related to some loader extensions (or not), all this room for unknowns leaves it at least reasonable to not wanting to be making these kinds of generalized statements — does not change the fact that code itself can benefit from knowing a little more about things to become more reliable.

[ljharb]

I think per your original question, it is indeed unreasonable to ask for a new feature because of “possible bugs” or because your code might be transformed in ways beyond your control.

Top level code already knows the context it’s in via this - your concern about that not being intuitive/explicit is a fair point, but that’s imo the only justification for any new features so far in this issue.

[devsnek]

@SMotaal

pursuing first-class detection by code itself

Right, but what does that enable us to do? That's the part I'm confused about.

[SMotaal]

unreasonable to ask for a new feature because of “possible bugs” Top level code already knows the context it’s in via this…

@ljharb but my point is not about bugs (only the tail I was constructively hoping to be respond to per your request)… or this being the keyword intentionally chosen in the spect to offer the "module" assertions reiterated many times above…

Just to point out this===undefined only incidentally happens to be fact in "module" being that "module" is always "strict" and this===undefined is actually the reality of "strict" itself.

---

but what does that enable us to do

@devsnek It is about concrete first-class reflection (an expectation that is not at all unreasonable)…

---

Sorry, once again, I really need to step away because I feel like my sincere efforts to be constructively working through every scenario posed (with sincere appreciation for them) ends up leaving over-saturating tails that are already addressed in the issue, and cannot be reiterated enough.

[ljharb]

You are right that it’s incidental, but it can still be used for this purpose all the same.

[devsnek]

reflection is good, but it should also be justified.

[SMotaal]

reflection is good, but it should also be justified.

@devsnek I feel a little unsure how all my effort here and your statement can be viewed not with some confusion (I am inclined to trust it is not intended to be offensive, dismissive… etc. not relevant in the context of our forum and mutual collaboration).

[devsnek]

@SMotaal it is very difficult to solve a problem if you don't know what the problem is. I would love to sit here and brainstorm, it's why I'm subscribed to issues here, but I still have no idea what the problem we're trying to solve is.

[SMotaal]

if dynamic import is available, static import is available.

@devsnek side question as I seem to have left things get stale in my mind…

• In a module context, import('./…') becomes host…('./…', referrer)

• In a script/global context, import('./…') becomes host…('./…', location) right? Or did that actually change to reflect src somehow too? nevermind — it seems to be the case

More to the point, in our implementation:

• In a cjs context, we are doing something like base = urlFromFilePath(__filename) for import('./…') correct?

[targos]

@SMotaal that's right

[bmeck]

Does this want some kind of change to be requested to the spec?

[devsnek]

it appears to want import.meta to be valid syntax and return undefined in a script.

[SMotaal]

@bmeck I guess the whole point of code deciding to respond to how it is loaded based on import.meta seems fair if import() already accounts to where it is loaded from.

So, yes, thanks @devsnek, but fair to note undefined here is just meant to stand in for something other than throwing SyntaxError. This would allow code to respond to type in a browser or equivalent. Now import() would likely not be the only way to continue loading its own dependencies, and authors get to decide how they want to do that.

[DerekNonGeneric]

FWIW, I've been able to detect the current goal w/o throwing SyntaxError with this one-liner.

const isModule = typeof module === 'undefined' ? true : false;

This is because module is not a global furnished in ES module context by any versions of Node.js thus far, while it is always furnished in a CommonJS context.

@SMotaal, does this solve for you?

[ljharb]

global.module = true anywhere in the app would break that code, though.

[DerekNonGeneric]

@ljharb, the same would apply for global.import.meta = true.

Of course, one would need to be careful. This check would need to be performed prior to any instantiation too. So rather than doing the following.

import module from 'module';

Prefer:

import { Module } from 'module';

Otherwise, it will also result in false-positives.

[devsnek]

import.meta is not a property lookup, it's a special syntax. you can't override it on global.