meteor-typescript

TypeScript in Meteor applications

Make the editor and checker resolve the intended Meteor declarations and actually inspect application source. Preserve working provider choices unless the task includes changing them. A runtime or bundler upgrade does not imply a declaration migration.

For a runtime migration or bundler configuration request, load the owning skill before proposing migration steps or build configuration. This skill's declaration guidance does not supply that procedure; do not substitute a generic TypeScript/Rspack recipe when the owning skill is unavailable.

Identify the layer

Layer	Evidence and action
Compilation	The Atmosphere typescript package or Rspack/SWC strips types. Use the build owner for syntax transforms, loaders and bundling.
Declaration provider	Inspect .meteor/packages, .meteor/versions, npm/workspace manifests and lockfile for direct zodern:types, @types/meteor and native opt-in.
Resolution	Inspect active tsconfig.json/jsconfig.json, extends, files, include, exclude, paths and types. Check the editor uses the intended project/compiler.
Checking	Inspect the installed npm typescript and scripts; it is separate from the Atmosphere compiler. Preserve a configured checker such as TsCheckerRspackPlugin.

Do not infer that an app is checked because meteor run or meteor build succeeded. Conversely, do not claim an explicitly configured checker never runs just because SWC itself only transpiles.

Choose the provider

Native package declarations are available on Meteor 3.6+.

Target and intent	Decision
Meteor 3 before 3.6	Native meteor types is unavailable. Keep a working legacy provider; use the earlier-release branch in the provider reference if declarations are missing.
New Meteor 3.6 TypeScript, TypeScript + Tailwind, Svelte or Angular app	The scaffold selects native declarations and meteor create generates them. Keep that provider; regenerate after cloning or changing packages.
Existing app upgraded to 3.6 with working legacy types	Keep its provider and paths unless native adoption is requested. A runtime upgrade does not migrate them.
Explicit native adoption on 3.6+	Root config required. Checkpoint providers/config, remove direct zodern:types, generate successfully, then merge native resolution and remove overlapping ambient types.
JavaScript-only 3.6+ app wanting IntelliSense	Use jsconfig.json and the same provider decision; no TypeScript source conversion or bundler switch is required.

Read declaration providers for the ordered switch, native adapter/barrel distinction, inherited configuration, TypeScript 7 compatibility, earlier providers and rollback. Read JavaScript IntelliSense for JS apps.

Verify the effective project

1. Confirm generation actually ran. A direct zodern:types makes meteor types skip with exit zero; meteor create generates for the four native scaffolds above. After cloning or changing packages, run meteor types explicitly; normal run, build, test and lint do not regenerate them.
2. Use the app's local compiler. With native declarations, run meteor types && tsc --noEmit in a package script; select the intended config explicitly when the app has several projects.
3. Check tsc --listFiles --noEmit includes application source. Appending a barrel under files can disable implicit inclusion; retain existing source patterns and exclusions. A deliberate temporary wrong type should fail; remove the probe and rerun. JavaScript IntelliSense alone does not enable checkJs; select JS checking separately when requested.
4. Restart the editor's TypeScript server after configuration changes. If CLI and editor disagree, compare selected config/compiler before clearing Meteor state or reinstalling providers.
5. Keep generated .meteor/types/ untracked and unedited. Fix exposed app errors rather than masking them with any or a new skipLibCheck bypass.

Diagnose the boundary

Symptom	First check
Native command reports nothing to do	Root tsconfig.json or jsconfig.json. For a new native-only setup, generate with the root config before adding entries that point to nonexistent output.
Generation fails	Read the error; local packages may need fixing. Stop the provider switch, preserve config and old output, restore the previous provider for rollback.
Ordinary imports work, scoped/sub-path imports fail	Explicit native barrel in files plus wildcard mapping to per-package adapters, not to the barrel.
Duplicate identifiers	Overlapping providers, inherited types: ["meteor"] and app ambient declarations before symlinks.
Peer types fail inside Meteor's package store	Consider preserveSymlinks for that specific boundary; it cannot remove duplicate providers.
User service fields are unknown, or OAuth signatures disagree	Use application augmentation and provider signatures; keep generated types unedited.
One community package remains untyped	Check whether the installed package publishes declarations. No generator can promise coverage for every Atmosphere package.
Generated relative imports or subscription handle types disagree with runtime	Check the native declaration contract in provider guidance, then regenerate and type-check. Keep generated files unedited and structural handles usable.

If the actual task is publishing package declarations, use the official Atmosphere package types documentation. Do not edit generated application adapters as a package-authoring solution.