mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
document .meteorignore and METEOR_IGNORE
This commit is contained in:
@@ -46,7 +46,7 @@ Starting with Meteor 3.4
|
||||
Add this Atmosphere package to your app:
|
||||
|
||||
``` bash
|
||||
meteor add rspack@1.0.0
|
||||
meteor add rspack
|
||||
```
|
||||
|
||||
On first run, the package installs the required Rspack setup at the project level. It compiles your app code with Rspack to get the full benefit of this integration.
|
||||
|
||||
@@ -11,6 +11,7 @@ The Meteor bundler is made up of key components that enhance your experience in
|
||||
- [**Minifier**](#minifier): Meteor uses the **SWC** minifier as a faster alternative to Terser.
|
||||
- [**Web archs**](#web-arch): Meteor now skips legacy architectures in development mode.
|
||||
- [**Watcher**](#watcher): Meteor now uses [`@parcel/watcher`](https://github.com/parcel-bundler/watcher) for a faster, more stable watch experience via native recursive file watching across all OS.
|
||||
- [**.meteorignore**](#meteorignore): Exclude files and directories from the bundler to reduce build and watch overhead.
|
||||
|
||||
## Quick start
|
||||
|
||||
@@ -44,6 +45,7 @@ You can also learn more about each part of the optimized components:
|
||||
- [**Minifier**](#minifier)
|
||||
- [**Web archs**](#web-arch)
|
||||
- [**Watcher**](#watcher)
|
||||
- [**.meteorignore**](#meteorignore)
|
||||
|
||||
---
|
||||
|
||||
@@ -522,6 +524,55 @@ METEOR_WATCH_POLLING_INTERVAL_MS=1000 METEOR_WATCH_FORCE_POLLING=true meteor run
|
||||
|
||||
---
|
||||
|
||||
## .meteorignore
|
||||
|
||||
> The `.meteorignore` file tells Meteor's bundler to skip specific files and directories, reducing unnecessary work during builds.
|
||||
|
||||
Meteor's bundler processes every file in your project tree by default. In projects with folders that are not part of the app, such as documentation, design assets, or standalone tooling, the bundler still traverses and watches those directories. This adds overhead to both initial builds and file-change recompilations.
|
||||
|
||||
You can place a `.meteorignore` file in any directory of your app or package. It uses the same pattern syntax as `.gitignore` and applies rules to the directory tree below it. Meteor's file watching system is fully integrated with `.meteorignore`, so you can add, remove, or modify these files during development and the changes take effect immediately.
|
||||
|
||||
### Example .meteorignore
|
||||
|
||||
Place this file at the root of your project as `.meteorignore`:
|
||||
|
||||
```gitignore
|
||||
# Documentation
|
||||
docs/
|
||||
|
||||
# Design and static assets not used by the app
|
||||
design/
|
||||
mockups/
|
||||
screenshots/
|
||||
|
||||
# CI/CD and infrastructure
|
||||
docker/
|
||||
|
||||
# Testing tools outside Meteor
|
||||
cypress/
|
||||
playwright/
|
||||
|
||||
# Scripts and tooling unrelated to the app
|
||||
scripts/
|
||||
tools/
|
||||
benchmarks/
|
||||
|
||||
# Misc
|
||||
LICENSE
|
||||
CHANGELOG.md
|
||||
CONTRIBUTING.md
|
||||
*.md
|
||||
!README.md
|
||||
```
|
||||
|
||||
This keeps the bundler focused on your actual app code and Meteor packages, skipping folders and files that have no role in the build. The result is faster rebuilds during development, especially in larger projects with significant non-app content.
|
||||
|
||||
You can also place `.meteorignore` files in subdirectories for more granular control. For example, a `.meteorignore` inside `packages/my-package/` applies only to that package's tree.
|
||||
|
||||
For a more dynamic approach, you can use the [`METEOR_IGNORE`](../../cli/environment-variables.md#meteor-ignore) environment variable to define ignore patterns per command without modifying project files. This is especially useful when you need different ignore rules for `meteor run` and `meteor test`.
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If you run into issues, try `meteor reset` or delete the `.meteor/local` folder in the project root.
|
||||
|
||||
@@ -18,7 +18,7 @@ Starting with Meteor 3.4
|
||||
Add this Atmosphere package to your app:
|
||||
|
||||
``` bash
|
||||
meteor add rspack@1.0.0
|
||||
meteor add rspack
|
||||
```
|
||||
|
||||
On first run, the package installs the required Rspack setup at the project level. It compiles your app code with Rspack to get the full benefit of this integration.
|
||||
|
||||
@@ -59,6 +59,42 @@ When running `meteor build` or `meteor deploy` you can set `METEOR_DISABLE_OPTIM
|
||||
|
||||
Since optimistic in-memory caching is one of the more memory-intensive parts of the build system, setting the environment variable `METEOR_DISABLE_OPTIMISTIC_CACHING=1` can help improve memory usage during meteor build, which seems to improve the total build times. This configuration is perfectly safe because the whole point of optimistic caching is to keep track of previous results for future rebuilds, but in the case of meteor `build` or `deploy` there's only ever one initial build, so the extra bookkeeping is unnecessary.
|
||||
|
||||
## METEOR_IGNORE
|
||||
(_development_)
|
||||
|
||||
An alternative way to exclude files and directories from the Meteor bundler, working similarly to a [`.meteorignore`](../about/modern-build-stack/meteor-bundler-optimizations.md#meteorignore) file but configured through an environment variable. This is useful when you want to ignore certain paths without modifying your project files.
|
||||
|
||||
The value should be a space-delimited list of patterns (following the same syntax as `.meteorignore`), for example: `METEOR_IGNORE="tests/* private/drafts"`.
|
||||
|
||||
When both `METEOR_IGNORE` and a `.meteorignore` file are present, their patterns are combined, so you can use the environment variable to complement your existing `.meteorignore` rules.
|
||||
|
||||
An interesting use case is to define different `METEOR_IGNORE` patterns per command. Since the variable is set per process, you can tailor what the bundler sees depending on whether you are running the app or running tests:
|
||||
|
||||
```bash
|
||||
# When developing, ignore test folders to speed up rebuilds
|
||||
METEOR_IGNORE="tests" meteor run
|
||||
|
||||
# When testing, ignore folders only needed for the running app
|
||||
# e.g. public/ assets that are not consumed by tests
|
||||
METEOR_IGNORE="public" meteor test --driver-package meteor/meteortesting:mocha
|
||||
```
|
||||
|
||||
You can also exclude heavy `node_modules` sub-dependencies that are only relevant to one workflow. For example, ignore test-only packages when running the app, or ignore app-only packages when running tests:
|
||||
|
||||
```bash
|
||||
# Ignore test-only dependencies when running the app
|
||||
METEOR_IGNORE="node_modules/puppeteer node_modules/playwright-core" meteor run
|
||||
|
||||
# Ignore heavy app-only dependencies when running tests
|
||||
METEOR_IGNORE="node_modules/pdfkit node_modules/sharp" meteor test --driver-package meteor/meteortesting:mocha
|
||||
```
|
||||
|
||||
This way each command only processes the files it actually needs, reducing build times on both workflows without requiring changes to your project's `.meteorignore` file.
|
||||
|
||||
:: info
|
||||
`METEOR_IGNORE` is automatically set when using the [Rspack bundler integration](../about/modern-build-stack/rspack-bundler-integration.md). Since Rspack handles the client and server app bundling, Meteor's bundler should only worry about what it strictly needs for the Meteor-Rspack integration. By using `METEOR_IGNORE` to exclude folders and dependencies that Rspack already manages or that are irrelevant to Meteor's side of the build, you ensure the most speed is gained from the Rspack delegation.
|
||||
::
|
||||
|
||||
## METEOR_PROFILE
|
||||
(_development_)
|
||||
|
||||
@@ -127,4 +163,3 @@ Configure Meteor's HTTP server to listen on a UNIX socket file path (e.g. `UNIX_
|
||||
(_production_)
|
||||
|
||||
This overrides the default UNIX file permissions on the UNIX socket file configured in `UNIX_SOCKET_PATH`. For example, `UNIX_SOCKET_PERMISSIONS=660` would set read/write permissions for both the user and group.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user