我总是发现自己试图回忆如何编写这个该死的代码片段，所以我决定为它创建一个简单的模块。我花了一点时间让它工作，因为访问调用者的模块信息并不简单，但看到它是如何做到的是很有趣的。

因此，其思想是调用一个模块，并询问调用方模块是否是主模块。我们必须算出调用函数的模块。我的第一个方法是对公认答案的一种变化:

module.exports = function () {
    return require.main === module.parent;
};

但这并不一定有效。模块。Parent指向将我们加载到内存中的模块，而不是调用我们的模块。如果是调用方模块将这个helper模块加载到内存中，那么就没问题。但如果不是，它就不会起作用。所以我们得试试别的办法。我的解决方案是生成一个堆栈跟踪，并从那里获得调用者的模块名:

module.exports = function () {
    // generate a stack trace
    const stack = (new Error()).stack;
    // the third line refers to our caller
    const stackLine = stack.split("\n")[2];
    // extract the module name from that line
    const callerModuleName = /\((.*):\d+:\d+\)$/.exec(stackLine)[1];

    return require.main.filename === callerModuleName;
};

保存为is-main-module.js，现在你可以这样做:

const isMainModule = require("./is-main-module");

if (isMainModule()) {
    console.info("called directly");
} else {
    console.info("required as a module");
}

这样更容易记。

我对解释中使用的术语有点困惑。所以我做了几个快速检查。

我发现它们产生了相同的结果:

var isCLI = !module.parent;
var isCLI = require.main === module;

对于其他困惑的人(并直接回答这个问题):

var isCLI = require.main === module;
var wasRequired = !isCLI;

我总是发现自己试图回忆如何编写这个该死的代码片段，所以我决定为它创建一个简单的模块。我花了一点时间让它工作，因为访问调用者的模块信息并不简单，但看到它是如何做到的是很有趣的。

因此，其思想是调用一个模块，并询问调用方模块是否是主模块。我们必须算出调用函数的模块。我的第一个方法是对公认答案的一种变化:

module.exports = function () {
    return require.main === module.parent;
};

但这并不一定有效。模块。Parent指向将我们加载到内存中的模块，而不是调用我们的模块。如果是调用方模块将这个helper模块加载到内存中，那么就没问题。但如果不是，它就不会起作用。所以我们得试试别的办法。我的解决方案是生成一个堆栈跟踪，并从那里获得调用者的模块名:

module.exports = function () {
    // generate a stack trace
    const stack = (new Error()).stack;
    // the third line refers to our caller
    const stackLine = stack.split("\n")[2];
    // extract the module name from that line
    const callerModuleName = /\((.*):\d+:\d+\)$/.exec(stackLine)[1];

    return require.main.filename === callerModuleName;
};

保存为is-main-module.js，现在你可以这样做:

const isMainModule = require("./is-main-module");

if (isMainModule()) {
    console.info("called directly");
} else {
    console.info("required as a module");
}

这样更容易记。

对于那些使用ES模块(和Node 10.12+)的用户，你可以使用import.meta.url:

import path from 'path';
import { fileURLToPath } from 'url'

const nodePath = path.resolve(process.argv[1]);
const modulePath = path.resolve(fileURLToPath(import.meta.url))
const isRunningDirectlyViaCLI = nodePath === modulePath

比如require。主要模块。parent和__dirname/__filename在ESM中不可用。

注意:如果使用ESLint，它可能会阻塞在这个语法上，在这种情况下，你需要更新到ESLint ^7.2.0，并把你的ecmaVersion调到11(2020)。

更多信息:进程。argv, import.meta.url

首先，让我们更好地定义问题。我的假设是，您真正要寻找的是您的脚本是否拥有进程。Argv(即你的脚本是否负责处理process.argv)。记住这个假设，下面的代码和测试是准确的。

模块。Parent工作得非常出色，但由于很好的原因(一个模块可能有多个父模块，在这种情况下，模块。父类只代表第一个父类)，所以使用下面的future-proof条件来覆盖所有情况:

if (
  typeof process === 'object' && process && process.argv
   && (
    (
      typeof module === 'object' && module
       && (
        !module.parent
         || require.main === module
         || (process.mainModule && process.mainModule.filename === __filename)
         || (__filename === "[stdin]" && __dirname === ".")
       )
    )
    || (
      typeof document === "object"
      && (function() {
       var scripts = document.getElementsByTagName("script");
       try { // in case we are in a special environment without path
         var normalize = require("path").normalize;
         for (var i=0,len=scripts.length|0; i < len; i=i+1|0)
           if (normalize(scripts[i].src.replace(/^file:/i,"")) === __filename)
             return true;
       } catch(e) {}
      })()
    )
   )
) {
    // this module is top-level and invoked directly by the CLI
    console.log("Invoked from CLI");
} else {
    console.log("Not invoked from CLI");
}

它在以下所有情况下的所有脚本中都正确工作，并且永远不会抛出任何错误†:

Requiring the script (e.x. require('./main.js')) Directly invoking the script (e.x. nodejs cli.js) Preloading another script (e.x. nodejs -r main.js cli.js) Piping into node CLI (e.x. cat cli.js | nodejs) Piping with preloading (e.x. cat cli.js | nodejs -r main.js) In workers (e.x. new Worker('./worker.js')) In evaled workers (e.x. new Worker('if (<test for CLI>) ...', {eval: true})) Inside ES6 modules (e.x. nodejs --experimental-modules cli-es6.js) Modules with preload (e.x. nodejs --experimental-modules -r main-es6.js cli-es6.js) Piped ES6 modules (e.x. cat cli-es6.js | nodejs --experimental-modules) Pipe+preload module (e.x. cat cli-es6.js | nodejs --experimental-modules -r main-es6.js) In the browser (in which case, CLI is false because there is no process.argv) In mixed browser+server environments (e.x. ElectronJS, in which case both inline scripts and all modules loaded via <script> tags are considered CLI)

唯一不工作的情况是当你预加载顶级脚本(例如nodejs -r cli.js cli.js)。这个问题不能通过管道(例如cat cli.js | nodejs -r cli.js)来解决，因为这会执行两次脚本(一次作为必需的模块，一次作为顶级模块)。我不相信有任何可能的解决办法，因为没有办法知道什么主脚本将从一个预加载的脚本。

†理论上，错误可能会从对象的getter内部抛出(例如，如果有人疯狂地执行object . defineproperty (globalThis， "process"， {get(){throw 0}});)，然而，对于任何环境中代码片段中使用的属性，在默认情况下这永远不会发生。

还有另一种稍短的方法(没有在提到的文档中列出)。

var runningAsScript = ！module.parent;

我在这篇博客文章中概述了更多关于这些工作原理的细节。