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
Right, but anything that's import()ed is also an entry point, and I'm very unclear on why you care what that value is. Currently you can look at process.argv and __filename to determine that (and import.meta.filename or similar is quite well motivated).
Also yes, main is a terrible name for multiple reasons, not the least of which is that it's a package.json field.
I really like the import.meta.main concept. Currently in Node.js it is common for CLI tools to do the following check:
if(require.main===module){console.log('This is a CLI tool! Usage: ...');}
We currently have no version of the above check in ECMAScript modules, so this is a problem that comes up, and there is currently no easy way to do this without it feeling like a hack.
As an already-paved use case, users are familiar with the main terminology in this context already.
The above check then becomes:
if(import.meta.main){console.log('This is a CLI tool! Usage: ...');}
and the really nice thing about this pattern is that it works in browsers and other environments completely fine without any need for compatibility API layers or compilation.
For these reasons I'm 100% supportive of import.meta.main.
Reacted by Evan Plaice, Bergi, Lucas Azzola, Nor, Jeroen Akkerman, Pavitra Golchha, Robert Jackson, Igor Strebz, Piyush Chauhan, HermannOnInvita and 88 more
Reacted by HermannOnInvita, onegen and Bruno Henriques
Doesn’t that use case predate the current community preference, which is to have separate packages for a library and a CLI?
Reacted by BlueNebulaDev, я котик пур-пур, Nyan Helsing, robross0606, Ren Hiyama, Shotaro Nakamura, Bruno Henriques, Ivan Kleshnin, Jarrod Davis, Mark Larah and 8 more
Sure but so is every aspect of the require algorithm :-) the better question is, is it still a common or desired use case to determine if something is the entry point, and how does that change now that dynamic import allows multiple entry points?
@ljharb yes it is a desired feature. The require.main === module was something we had to explicitly support in the ncc project as users were using it in CLI tools. This came up pretty early in the project and had multiple users asking about it here - vercel/ncc#224. Dynamic import does not affect this, as what we are distinguishing is the CLI entry point, not the module graph entry point.
Reacted by Brian Kim, ExE Boss, Roy Ivy III, Tomáš Hübelbauer, Ian Walter, Matthieu Gindre, BlueNebulaDev, Kevin Gibbons, Owen Buckley, я котик пур-пур and 5 more
I'm not a huge fan of the concept of main. imo you should have separate files for bin and lib, which is something other languages do just fine, and installers like npm and yarn already let you specify separate bins.
Reacted by Jordan Harband and Charles Samborski
Reacted by BlueNebulaDev, David Ankin, Aurélien Bertron, я котик пур-пур, onegen, Ivan Kleshnin, Jeff Seaman, Jakub21, Estevão Soares dos Santos, Matt Krins and 4 more
@shian15810 thanks for showing an interest in the modules work! Contributions are very much welcome to Node.js core and the module work here.
We do have some consensus issues for this feature due to our not wanting to provide unnecessary features without seeing a strong need for them in the initial modules implementation. import.meta is a very widely used namespace (every module!) with strong backwards compatibility needs, so we do also need to be very cautious about what we put on it.
A PR to Node.js core would certainly drive discussion, and may even sway consensus. Also hearing more about your use case as a CLI maintainer and how this is useful could help us better understand the importance of the feature to you (including for example the points raised by Gus above). Even if the PR sits without approval, we may be able to come back to it in a few months even as well.
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the
never-staleIssues and PRs exempt from automated stale handling.
label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
I read all the comments but I can't understand why this issue is still open after 3 years but it's not going anywhere.
Are you still stuck deciding whether you want this feature at all, or what else is blocking this? After longer than three years and a hundred comments I think it's time to decide: please close the issue if you really don't want it.
As @Beedeebee said almost 3 years ago, can we have an official position if this is going forward or not?
I see that the problem is that no one wants to commit to decide and being responsible if the outcome goes sideways. That will always be the problem with decisions by committee. However, as both Deno an Bun have import.meta.main, it's only logical to just behave the same.
import{createRequire}from'node:module'import{fileURLToPath}from'node:url'constextRegExp=/\.[^./\\]*$/conststripExt=(path: string)=>path.replace(extRegExp,'')exportconstisMain=(meta: ImportMeta,cmd=process.argv[1]): boolean=>// Unlike path.resolve, require.resolve returns a real path,// so it is compatible with package bins in node_modules/.bin,// e.g. when running via npx/pnpx.!!meta&&!!cmd&&stripExt(fileURLToPath(meta.url))===stripExt(createRequire(meta.url).resolve(cmd))
And yes, having import.meta.main compatible with Deno and Bun would be optimal, IMO.
Should be reopened, but not sure one can transfer ownership of this issue though? As @MylesBorins seems to wants all of his GitHub issues closed now I guess that should also be respected?
If you want to work on making this happen I'd say open another issue and reference this one. GitHubs design makes any open issues I've created a never ending Todo list / noise.
Think of it like forking 😄
Reacted by Roy Ivy III, Ivan Uhalin and Pooya Parsa
Ugh, considering moving back from bun for my scripts and thought most of the friction would be gone after the release of --experimental-strip-types, but hit this immediately.
Activity
ljharb commentedon Feb 26, 2019
I'm a bit confused what it does - does it mean "it was the
mainin package.json"? it was the primary entry point? what aboutimport()?devsnek commentedon Feb 26, 2019
it's true if the file was the entrypoint. for node i'd rather it be called something else cuz the term main already has package-scoped meaning.
ljharb commentedon Feb 26, 2019
Right, but anything that's
import()ed is also an entry point, and I'm very unclear on why you care what that value is. Currently you can look atprocess.argvand__filenameto determine that (andimport.meta.filenameor similar is quite well motivated).Also yes,
mainis a terrible name for multiple reasons, not the least of which is that it's a package.json field.guybedford commentedon Feb 27, 2019
I really like the
import.meta.mainconcept. Currently in Node.js it is common for CLI tools to do the following check:We currently have no version of the above check in ECMAScript modules, so this is a problem that comes up, and there is currently no easy way to do this without it feeling like a hack.
As an already-paved use case, users are familiar with the
mainterminology in this context already.The above check then becomes:
and the really nice thing about this pattern is that it works in browsers and other environments completely fine without any need for compatibility API layers or compilation.
For these reasons I'm 100% supportive of
import.meta.main.ljharb commentedon Feb 27, 2019
Doesn’t that use case predate the current community preference, which is to have separate packages for a library and a CLI?
guybedford commentedon Feb 27, 2019
@ljharb this use case is explicitly documented in https://github.com/nodejs/node/blob/master/doc/api/modules.md#accessing-the-main-module.
ljharb commentedon Feb 27, 2019
Sure but so is every aspect of the require algorithm :-) the better question is, is it still a common or desired use case to determine if something is the entry point, and how does that change now that dynamic import allows multiple entry points?
guybedford commentedon Feb 27, 2019
@ljharb yes it is a desired feature. The
require.main === modulewas something we had to explicitly support in the ncc project as users were using it in CLI tools. This came up pretty early in the project and had multiple users asking about it here - vercel/ncc#224. Dynamic import does not affect this, as what we are distinguishing is the CLI entry point, not the module graph entry point.ljharb commentedon Feb 27, 2019
The feature seems fine then (it’d only be true in the top-level process entry point); the name, definitely not (but we can bikeshed that).
bmeck commentedon Feb 27, 2019
Does this absolutely need to be in our first iteration or can we get feedback / focus on other things?
zenparsing commentedon Feb 27, 2019
Thanks for bringing this up @MylesBorins. I (think) we can say this is post-MVP but it's good to have on our radar.
MylesBorins commentedon Feb 27, 2019
can definitely be post MVP. Just wanted to document what's going on in ecosystem
shian15810 commentedon Aug 1, 2019
Well, I'm not part of the organization, but as a cli maintainer, this proposal seems so interesting.
Can I start to try implementing this in https://github.com/nodejs/node and possibly a PR now?
devsnek commentedon Aug 1, 2019
I'm not a huge fan of the concept of main. imo you should have separate files for bin and lib, which is something other languages do just fine, and installers like npm and yarn already let you specify separate bins.
guybedford commentedon Aug 1, 2019
@shian15810 thanks for showing an interest in the modules work! Contributions are very much welcome to Node.js core and the module work here.
We do have some consensus issues for this feature due to our not wanting to provide unnecessary features without seeing a strong need for them in the initial modules implementation.
import.metais a very widely used namespace (every module!) with strong backwards compatibility needs, so we do also need to be very cautious about what we put on it.A PR to Node.js core would certainly drive discussion, and may even sway consensus. Also hearing more about your use case as a CLI maintainer and how this is useful could help us better understand the importance of the feature to you (including for example the points raised by Gus above). Even if the PR sits without approval, we may be able to come back to it in a few months even as well.
97 remaining items
github-actions commentedon Jan 2, 2025
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-staleIssues and PRs exempt from automated stale handling.
label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
arslivinski commentedon Jan 30, 2025
As @Beedeebee said almost 3 years ago, can we have an official position if this is going forward or not?
I see that the problem is that no one wants to commit to decide and being responsible if the outcome goes sideways. That will always be the problem with decisions by committee. However, as both Deno an Bun have
import.meta.main, it's only logical to just behave the same.Otherwise, we could just close this issue and discuss this on WinterTC (TC55) WinterTC55/proposal-minimum-common-api#46 probably for more 3 years.
iki commentedon Feb 5, 2025
Would be great to have a proper solution, because it should be easy to use, but it's not as simple to even get it right currently.
For example, es-main works ok, but is-main does not.
And yes, having
import.meta.maincompatible with Deno and Bun would be optimal, IMO.voxpelli commentedon Feb 25, 2025
Should be reopened, but not sure one can transfer ownership of this issue though? As @MylesBorins seems to wants all of his GitHub issues closed now I guess that should also be respected?
MylesBorins commentedon Feb 25, 2025
If you want to work on making this happen I'd say open another issue and reference this one. GitHubs design makes any open issues I've created a never ending Todo list / noise.
Think of it like forking 😄
rivy commentedon Feb 25, 2025
Understandable.
It has been 5 years.
I also close my long standing, "non-resolving" issues to clear my "to-do" list periodically.
chore(deps-dev): add es-main
build(deps-dev): add es-main
rhyek commentedon Apr 30, 2025
Ugh, considering moving back from bun for my scripts and thought most of the friction would be gone after the release of
--experimental-strip-types, but hit this immediately.