CodeVetter · Repo Unpack · System map
meteor/meteor
Meteor separates the developer-facing tool from the runtime embedded in generated applications. ProjectContext and Isobuild own dependency preparation and compilation, while runtime packages own HTTP, DDP, authentication, and database behavior. Rspack introduces additional bundler processes, and standalone bundles expose a Node.js deployment boundary.
- The meteor launcher selects dev_bundle/bin/node and tools/index.js; index.js first handles bundled binary commands, otherwise installs the Babel hook and loads cli/main.
- CLI command registration is centralized in main.registerCommand; main loads separate general, package, package-query, Cordova, and alias modules.
- ProjectContext exposes staged metadata reading, catalog initialization, constraint resolution, package downloading, local compilation, and final metadata preparation.
- Isobuild represents compiled packages as Isopacks and architecture-specific Unibuilds; Bundler coordinates compilation and Builder writes artifacts and watch-set metadata.
- Runner constructs the development proxy and chooses external MongoDB, a MongoRunner when mongo-dev-server is available, or the no-mongo-server sentinel.
- Application runtime boundaries include WebApp's Express/HTTP server, DDP method and publication registries, and MongoConnection's native-driver persistence.
- The rspack package registers a build plugin and server module; its process layer independently launches a client serve process and a server build --watch process.
- Standalone bundles write main.js and deployment instructions for Node.js, MONGO_URL, ROOT_URL, MAIL_URL, METEOR_SETTINGS, and PORT; root test scripts and the Hexo documentation builds have separate execution contexts.