import.meta.main

[arslivinski]

What is the problem this feature will solve?

We need an easy way to know if the current file was the one executed by Node.

What is the feature you are proposing to solve the problem?

Following of #49440

Deno and Bun have it, Node should have it too.

What alternatives have you considered?

No response

[ljharb]

I'm fine with the feature, but calling it "main" is very confusing, since anything that's import()ed is an entry point, and "main" already exists.

(Also, I'd hope that node would add things not solely because some alternatives have it, but because it's independently motivated)

[arslivinski]

@ljharb I get your point of not doing something just because others did it. But at the same time, I see that by taking so long to take a decision on this, that others decided first and now the ecossystem is using import.meta.main. It's a ship that already sailed.

Also, I didn't mention entrypoint, but if the current file was the one executed by Node, like by running node someFile.js.

[Lordfirespeed]

@ljharb you say "main" already exists, can you explain more specifically?

IMO it makes sense to name this main. Not only does this improve inter-operability between the 'big' JavaScript runtimes, but there is significant precedent, really too much to ignore.

• Python: if __name__ == "__main__": foo()
• C/C++: int main() { ... }
• Rust: fn main() { ... }
• Java (preview 24): void main() { ... }
• Kotlin: fun main() { ... }
• C#: static void Main(string[] args) { ... }
• Go: func main() { ... }

In all of these cases main refers to a special name/value which says 'here is where the magic happens'.

[ljharb]

@Lordfirespeed i mean the "main" field of package.json, which is the entrypoint of a package when exports is not present.

[Lordfirespeed]

@Lordfirespeed i mean the "main" field of package.json, which is the entrypoint of a package when exports is not present.

Ah, yes, thankyou for reminding me.

To me, this corroborates that naming this feature main makes sense - the desired behaviour is that import.meta.main evaluates true in the main file (of the package.json variety), and false otherwise, in the case that one runs e.g. npm start.

You don't agree? 😅

[ljharb]

"main" in package.json means "an entry point", and every dynamic-imported file is an entry point - but #57226 (comment) confirms that that's not the intended semantic, which means "main" is objectively the wrong name for it.

If it's intended to be true in every graph root - iow, anything ran directly by node AND anything import()ed - then "main" would be an appropriate name - but only if that's the case.

[Lordfirespeed]

"main" in package.json means "an entry point"

My interpretation of it is that it defines the primary entry point to your package - npm seems to agree with this ref

If [and only if] it's intended to be true in every graph root [...] then "main" would be an appropriate name

I see what you're getting at, I commend your technical correctness ♥️

Call it an abuse of notation for the sake of adhering to popular convention, then.
The most comparable case here is Python, the next most popular interpreted language; by your reasoning, Python's __name__ == "__main__" is a misnomer.

I think the popular opinion will be that familiarity trumps correctness, as unsatisfying as that may be.

[ljharb]

Node’s most important consumer isn’t a polyglot, though - most JS devs have only ever learned JS. Prior art is important, but that doesn’t mean we should be constrained by what other languages do - and since node has the main field, it has a conflation all the others don’t - so it should also have a solution that all the others don’t.

[Lordfirespeed]

most JS devs have only ever learned JS

Here's the raw data for the JetBrains State of Developer Ecosystem Survey 2024.

The survey had 23,262 respondents.
Respondents were asked: What are your primary programming languages?
The survey data suggests that 65.3% of 'primary' JavaScript developers consider (at least one of) Java, PHP, Python or C# to be one of their primary programming languages.
Excluding PHP from the above list (it doesn't follow the main paradigm), we are still left with a 53.8% majority.

I am happy to accept arguments that the data may be skewed due to collection methods / circumstances, though.

since node has the main field, it has a conflation all the others don’t

I'm still strongly of the opinion that the main field corroborates with import.meta.main, and would not be a conflation

[jasnell]

Whatever else main might mean is not super important here. The definition of import.meta.main is the same that Deno defines here: https://docs.deno.com/runtime/reference/deno_namespace_apis/#import.meta.main

https://github.com/wintercg/import-meta-registry

[Lordfirespeed]

Also Bun. https://bun.sh/docs/api/import-meta

[joyeecheung]

If people didn’t have problems with require.main I don’t see how import.meta.main is going to be a problematic name? I see it less so for aligning with what other runtimes do (it would be an unfortunate situation if it becomes “whoever gets to this name first gets to dictate the API, no matter the API makes sense or not in other runtimes”), but more so for bringing import.meta on par with what require offers (we already have import.meta.resolve for bringing it on par with require.resolve, for example).