import(cjs) messes with module.parent

[aduh95]

Some packages use a check on module.parent to know if they are launched from CLI or required by another module:

// module.cjs
if (!module.parent) throw new Error("Running from CLI is not supported!");

This works fine if you use require (I tried from both CJS and ES modules):

$ node -p "assert.doesNotThrow(()=>require('./module.cjs')), 'No error!';"
No error!

However, when importing from ESM, that doesn't work:

// module.mjs
import './module.cjs'; // This will throw the "don't run from CLI" Error...
console.log('This is fine.'); // This is never reached

Same for dynamic imports:

// module.js // (same behaviour on ESM and CJS)
import('./module.cjs')
  .then(()=>console.log('This is fine.'))
  .catch(()=>console.log('Oh no!'))

I can see three ways to tackle this issue, but none is very satisfying to me:

• Make module.parent truthy when a CJS is imported (although I have no idea what it could look like).
• Deprecate module.parent? Packages using require.main===module are fine, so that's what library authors should be using to test this, right?
• Disregard this issue, as users can use module.createRequire to workaround the issue.

[jkrems]

Thanks for bringing this up, I don't think we were tracking this yet! Your options sound spot-on.

Make module.parent truthy when a CJS is imported (although I have no idea what it could look like).

Making module.parent could be tricky if any package actually tries to check it - it would have to be something that itself isn't a valid CJS module. So we'd have to select a value very carefully or risk breaking other uses of module.parent if those exist.

Packages using require.main===module are fine, so that's what library authors should be using to test this, right?

Yeah, I think to me require.main===module is the "canonical" check. That's also what the docs suggest using: https://nodejs.org/api/modules.html#modules_accessing_the_main_module. So for maintainers, the suggested path would be to migrate to that pattern instead.

Disregard this issue, as users can use module.createRequire to workaround the issue.

I think it'll depend on how widespread this issue is. Can you share which package (or packages) this happened with? Capturing a list here may make it easier for us to determine the impact.

[SimenB]

One use case for module.parent, fwiw: https://github.com/hypercloud/import-dir/blob/afb1ef9ae1849e6ce8b535f69d412e38dda3115b/index.js#L14. Not a highly used module, but still

[bmeck]

@SimenB not all ESM have a valid file path associated with them (data: in particular for now), and/or there may have multiple ESM with the same file path but different URLs (using URL fragments). I'm not sure we could preserve that through populating module.parent from an ESM base.

[aduh95]

For reference, I have seen is-port-available and pdf-parse use a similar pattern. Not highly used modules either, but there are certainly others.

[ExE-Boss]

I think we should deprecate module.parent.

[DerekNonGeneric]

Folks, I'm very much opposed to deprecating module.parent.

In fact, I'm in need of this feature to be functional for ES modules too.

The intended use-case is to be able to visualize module graphs. To be able to traverse these graphs, I'd need this parent-children relationship metadata. This also relates to APMs.

Additionally, I do not think something so important should be deprecated merely to discourage a pattern.

[devsnek]

@DerekNonGeneric parent does not give an accurate traversal of a graph anyway, because modules can actually have multiple parents. you should start at the entrypoint and traverse down.

[DerekNonGeneric]

I'm sorry, can you clarify? I'm aware CJS and ES modules use different algorithms, but module.parent shows undefined in my .mjs graphs anyways, so I was referring to CJS graphs. I'd appreciate a link to spec docs if possible.

[devsnek]

@DerekNonGeneric like require('x.js') in a.js and require('x.js') in b.js. Both a.js and b.js are parents of x.js, but only the one that ran first would be the module.parent.

[DerekNonGeneric]

That's perfectly fine! I'm interested in visualizing the graph as it exists during execution (not conceptually).

[devsnek]

@DerekNonGeneric ... during execution both a.js and b.js required x.js. a cjs module graph would show a directed edge from a.js to x.js and a directed edge from b.js to x.js.

[DerekNonGeneric]

I'm unclear why this information would be useful to a stack trace, but unavailable to userland. I'd have to do more research, but this seems like valuable information is being lost.