com um clique
conventions
Use when writing new packages, adding CLI commands, creating build plugins, or following Meteor code patterns. Covers package.js structure, file naming, and common code patterns.
Menu
Use when writing new packages, adding CLI commands, creating build plugins, or following Meteor code patterns. Covers package.js structure, file naming, and common code patterns.
| name | conventions |
| description | Use when writing new packages, adding CLI commands, creating build plugins, or following Meteor code patterns. Covers package.js structure, file naming, and common code patterns. |
Package structure, file naming, and code patterns for the Meteor codebase.
Every Meteor package follows this structure:
packages/my-package/
├── package.js # Package manifest (name, version, dependencies, exports)
├── my-package.js # Main implementation (or split by concern)
├── my-package-server.js # Server-only code (optional)
├── my-package-client.js # Client-only code (optional)
├── my-package-tests.js # Tests (loaded via api.addFiles in test mode)
└── README.md # Documentation (optional)
Package.describe({
name: 'my-package',
version: '1.0.0',
summary: 'Brief description',
git: 'https://github.com/meteor/meteor.git',
documentation: 'README.md'
});
Package.onUse(function(api) {
api.versionsFrom(['3.0']); // Minimum Meteor version
api.use([
'ecmascript', // ES2015+ support
'mongo', // MongoDB integration
'tracker' // Reactivity (client)
]);
api.use('accounts-base', { weak: true }); // Optional dependency
api.mainModule('my-package-server.js', 'server');
api.mainModule('my-package-client.js', 'client');
api.export('MyPackage'); // Global export
});
Package.onTest(function(api) {
api.use(['tinytest', 'my-package']);
api.addFiles('my-package-tests.js');
});
Npm.depends({
'lodash': '4.17.21' // npm dependencies
});
| Pattern | Purpose |
|---|---|
*-server.js | Server-only code |
*-client.js | Client-only code |
*-common.js | Shared code |
*-tests.js | Test files |
*.d.ts | TypeScript declarations |
/packages/my-package/package.js with proper dependencies*-tests.jsKey files to understand:
/tools/isobuild/bundler.js - High-level bundling/tools/isobuild/compiler.js - Package compilation/tools/project-context.js - Dependency resolution/tools/cli/commands.js - CLI command handlersEdit /tools/cli/commands.js or create new command file:
main.registerCommand({
name: 'my-command',
options: {
'option-name': { type: String, short: 'o' }
},
catalogRefresh: new catalog.Refresh.Never()
}, function(options) {
// Implementation
});
import { WebApp } from 'meteor/webapp';
// Add middleware before Meteor's default handlers
WebApp.rawConnectHandlers.use('/api', (req, res, next) => {
// Runs before authentication
next();
});
// Add middleware after authentication
WebApp.connectHandlers.use('/api', (req, res, next) => {
// req.userId available if authenticated
next();
});
// In package.js
Package.registerBuildPlugin({
name: 'compile-my-files',
use: ['ecmascript', 'caching-compiler'],
sources: ['plugin.js'],
npmDependencies: { 'my-compiler': '1.0.0' }
});
// In plugin.js
Plugin.registerCompiler({
extensions: ['myext'],
archMatching: 'web'
}, () => new MyCompiler());
class MyCompiler extends CachingCompiler {
getCacheKey(inputFile) {
return inputFile.getSourceHash();
}
compileOneFile(inputFile) {
const source = inputFile.getContentsAsString();
const compiled = transform(source);
inputFile.addJavaScript({
data: compiled,
path: inputFile.getPathInPackage() + '.js'
});
}
}
// In package.js
api.use('tools-core');
// In implementation
import {
logProgress,
checkNpmDependencyExists,
getMeteorAppConfig,
spawnProcess
} from 'meteor/tools-core';
// Check and install dependencies
if (!checkNpmDependencyExists('@rspack/core')) {
installNpmDependency(['@rspack/core@^1.7.1']);
}
// Spawn external process
const proc = spawnProcess('npx', ['rspack', 'build'], {
cwd: getMeteorAppDir(),
onStdout: (data) => logProgress(data)
});
Meteor uses X.Y.Z-rcN.M versioning where:
X.Y.Z - Semantic versionrcN - Release candidate numberM - Package-specific revisionUse when writing tests, debugging test failures, running the test suite, or setting up test infrastructure. Covers self-test, package tests, and modern E2E tests.
Use when bumping Meteor package versions for beta, RC, or official releases. Covers the two version schemes (meteor-tool vs all other packages), the update-semver automation tool, manual files the tool does not handle, and the full lifecycle from beta through official release. Applies to packages/*/package.js, scripts/admin/, npm-packages/meteor-installer/, and .meteor/versions in test apps.
Use for writing, reviewing, editing, or generating Meteor release changelog entries. Defines canonical file locations, naming rules, required section structure, formatting conventions, PR-based generation workflow (with gh CLI and web fallback), incremental updates, and common entry patterns. Applies to files under v3-docs/docs/generators/changelog/versions/.
Use when analyzing release branch changes for missing user-facing documentation. Compares the release branch against devel, filters for user-facing changes, scans v3-docs/docs/ for coverage, and produces a gap report (.md file) with prioritized documentation opportunities. Does NOT write documentation — only identifies gaps and outputs a plan for later action.
Use when adding, modifying, or reviewing E2E test apps/skeletons to keep the test coverage report up to date.
Use when creating, updating, or maintaining AI documentation files (AGENTS.md, CLAUDE.md, skills). Covers file structure, conventions, and guidelines for evolving AI context.