这很复杂。
meteor run
命令会将你的项目文件复制到 <project-dir>/.meteor/local/build
目录下的一组目录树中,以非明显的方式重新组织它们(例如原始目录中的 private 子目录变成了 assets 子目录),并与各种 npm 模块混合在一起创建一个可作为 node.js 项目执行的包。事实上,为了避免重复,.meteor 目录中自动设置了 .gitignore 文件,告诉 Git 不要复制 .meteor/local 目录(如果你使用 Git 进行版本控制)。
原始项目目录会被监视,以防更改文件。然后,更改会被复制到当前项目构建目录中,并重新构建项目。
如果你部署到远程系统,则构建会被复制到服务器并运行。
process
通常是一个已定义的全局服务器端对象,按照 node.js API 工作,因为 meteor 服务器代码最终在 node.js 中运行。
因此,你可以在服务器端运行 console.log(process.cwd());
来获取服务器进程的当前工作目录,通常类似于:
~/<meteor project directory>/.meteor/local/build/programs/server
meteor run
时,原始项目文件位于../../../../../
,但不要使用它,因为它可能会在将来更改。baseDir = process.cwd().replace(/\/\.meteor.*$/, '');
这会获取工作目录,并截断以/.meteor
开头的所有内容。
然而,对于服务器部署,这并不适用,因为服务器上不需要原始项目树,只需要构建。未打算用于客户端或服务器端代码的文件可能会被粘在私有子目录中,正如我之前提到的它将成为构建中的资产子目录。目前找到构建中的文件的方法要么是手动检查本地运行中的 .meteor/local 文件,要么使用调用或模拟gnu find的JS库。
既然你提到了packages,我注意到在构建中,服务器端包代码最终会出现在:
~/<project-dir>/.meteor/local/build/programs/server/packages
并且客户端方面有:
~/<project-dir>/.meteor/local/build/programs/web.browser/packages