Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seemingly-inconsistent fallback behavior #15

Open
jugglinmike opened this issue Oct 24, 2017 · 1 comment
Open

Seemingly-inconsistent fallback behavior #15

jugglinmike opened this issue Oct 24, 2017 · 1 comment
Labels

Comments

@jugglinmike
Copy link

As of version 1.0.2, this module returns the current working directory when the "main" module cannot be identified:

  if (main && isIISNode(main)) return handleIISNode(main)
  else return main ? main.filename : process.cwd()

This means the return value may describe a file or a directory; consumers must determine which before they can use it safely. Because this behavior is undocumented, I first guessed this was an oversight. However, there is an explicit test for it:

  it('should default to process.cwd() if require.main is undefined', function () {
    requireMainFilename({}).should.match(/require-main-filename/)
  })

Can any of the maintainers explain the rationale for this behavior? And since it differs from the Node.js feature that this module is intended to mimic, can that be added to the project documentation?

I'm also curious if the function signature could be extended with an "options" object to enable "strict" behavior, where undefined is returned in cases where the main module is undefined.

@bcoe bcoe added the question label Jan 28, 2019
@bcoe
Copy link
Member

bcoe commented Jan 28, 2019

@jugglinmike sorry for ignoring this for so long; I don't honestly remember the original reasoning for falling back to process.cwd. We're getting close to retiring require-main-filename for some contexts in yargs, via yargs/yargs#1262.

I also wonder will main.filename ever not be set in Node>6? I wonder what edge-case we were protecting against here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants