Upgrading Atmosphere build pipeline for SWC/Rspack and modern ES6 libraries
Problem Statement
Modern ES6 libraries like helia.js (IPFS) and cornerstone3d.js (medical imaging) compile successfully when added to the main Meteor application but break when added to Atmosphere packages. This document outlines strategies for upgrading the Atmosphere package compile
pipeline to use SWC and support modern ES6/ESM libraries.
Claude Prompt
Claude, I’ve attached you to a local copy of https://github.com/meteor/meteor, which contains the meteor.js build tool. One simple request: please ultrathink on strategies for upgrading the Atmosphere package compile pipeline to also use Speedy Web Compiler, and to support modern ES6 libraries, such as helia.js and cornerstone3d.js (which will compile when those npm libraries are added to the main application, but break when added to an atmosphere package). You may wish to refer to https://forums.meteor.com/, https://github.com/meteor/meteor/issues, and https://github.com/meteor/meteor/discussions for more information on the current state of the refactor to SWC and Rspack in the main app and in the Atmosphere build pipeline.
Current State Analysis
SWC Integration Status
- SWC is already integrated in Meteor 3.3+ for main app transpilation
- Location: /packages/babel-compiler/babel-compiler.js (v1.12.14 of @meteorjs/swc-core)
- Automatic fallback to Babel for incompatible code (nested imports, React compiler)
- Minification also uses SWC (/packages/standard-minifier-js/plugin/minify-js.js)
Why Modern Libraries Break in Atmosphere Packages
Critical Files in Build Pipeline
/tools/isobuild/resolver.ts - Module resolution (mainFields, exports)
/tools/isobuild/compiler.js - Main compilation orchestration
/tools/isobuild/compiler-plugin.js - Plugin system, ImportScanner
/tools/isobuild/linker.js - Module linking (namespace differences)
/tools/isobuild/bundler.js - NodeModulesDirectory isolation
/tools/isobuild/import-scanner.ts - Module dependency scanning
/packages/babel-compiler/ - SWC/Babel transpilation
/packages/modules-runtime/ - Runtime module resolution
Meteor Roadmap Context
- Phase 5 (Meteor 3.4): External bundler integration (Rspack/ESBuild/Rollup)
- Next Releases: “Support package.json exports fields” listed as priority
- Ongoing: PR #13520 for exports field support
Recommended Implementation Strategies
Strategy 1: “SWC Parity for Packages” (Immediate - Low Risk)
Goal: Enable the same SWC transpilation in packages that the main app already uses.
Modifications:
/packages/babel-compiler/babel-compiler.js
- Remove default excludePackages behavior
- Add package-aware SWC configuration inheritance
- Handle package-specific Reify post-processing
/tools/isobuild/resolver.ts(lines 102-113)
// CURRENT (server only uses main):
this.mainFields = ["main"];
// PROPOSED (server can use module field):
this.mainFields = ["module", "main"];
/packages/modules-runtime/server.js
- Enhance Module.prototype.useNode for ESM imports via dynamic import
Complexity: 2-3 weeks | Risk: Low | Library Support: Partial
Strategy 2: “Modern Module Resolution” (Primary - Medium Risk)
Goal: Complete package.json “exports” field support and unify resolution across app/packages.
Modifications:
/tools/isobuild/resolver.ts- Major enhancements
- Complete exports field implementation (building on commit bb90b23c7e)
- Add condition resolution: import, require, node, browser, default
- Support conditional exports with nested conditions
- Handle self-referencing packages
// Add conditions based on architecture
private conditions: string[];
// Server:
this.conditions = ['node', 'import', 'require', 'module-sync', 'default'];
// Web:
this.conditions = ['browser', 'import', 'module', 'default'];
/tools/isobuild/import-scanner.ts(lines 159-198)
- Respect type: “module” in package.json
- Handle .mjs files natively without Reify transformation
- Support import assertions/attributes
/tools/isobuild/compiler-plugin.js(lines 1243-1252)
- Add exports field awareness to PackageSourceBatch.getResolver()
- Pass appropriate conditions based on target architecture
/tools/isobuild/linker.js(lines 528-587)
- Support ESM native output format
- Handle type: “module” packages without closure transformation
Complexity: 4-6 weeks | Risk: Medium | Library Support: Good
Strategy 3: “External Bundler Delegation” (Future - Aligned with 3.4)
Goal: Allow packages to opt-in to Rspack/ESBuild processing for their dependencies.
Modifications:
- New File: /tools/isobuild/external-bundler.js
- Abstraction layer for external bundlers
- Package author configuration interface
- /tools/isobuild/bundler.js (NodeModulesDirectory)
- Support pre-bundled node_modules
- Handle meteor.bundler package.json configuration
- Package Configuration Schema:
{
"meteor": {
"bundler": {
"type": "rspack",
"entry": "./src/index.js",
"externals": ["meteor/*"]
}
}
}
Complexity: 8-12 weeks | Risk: Medium | Library Support: Excellent
Strategy 4: “ESM-First Package Format” (Long-term)
Goal: New package format with native ESM support.
New Format Example (meteor-package.json):
{
"name": "my-package",
"version": "1.0.0",
"type": "module",
"exports": {
".": "./src/index.js",
"./client": "./src/client.js"
},
"meteor": {
"depends": ["meteor", "mongo"],
"provides": ["my-api"]
}
}
Complexity: 10-14 weeks | Risk: Medium | Library Support: Excellent
Recommended Implementation Order
Phase 1 (Immediate - Meteor 3.4.x):
├── Strategy 1: SWC Parity for Packages
└── Strategy 2: Modern Module Resolution (Priority)
Phase 2 (Meteor 3.5):
└── Strategy 3: External Bundler Delegation
Phase 3 (Meteor 4.0):
└── Strategy 4: ESM-First Package Format
Verification Plan
- Create test packages with helia.js and cornerstone3d.js as dependencies
- Build and run on all architectures (os, web.browser, web.browser.legacy)
- Verify imports resolve correctly from both package code and app code
- Check bundle sizes and build times before/after
- Test HMR functionality with package changes