meteor-typescript
Skill10 starsChanged 3 months agoMITView on GitHub
Use when setting up or repairing Meteor application declarations, TypeScript configuration, JavaScript IntelliSense, or local and CI type-checking. Triggers on meteor types, meteor/* imports resolving to any, missing declarations, duplicate Meteor identifiers, zodern:types, @types/meteor, .meteor/types, tsconfig.json, jsconfig.json, and tsc --noEmit in a Meteor app. Use this skill when choosing or migrating declaration providers without changing the app's runtime or bundler. For a Meteor 2-to-3 runtime migration use migrate-to-meteor-3 first; for SWC/Rspack compilation use meteor-modern-build-stack or migrate-to-rspack. General TypeScript language questions and Atmosphere declaration publishing are outside this app scope.
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- wekan/wekanedited, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- wekan/wekan★ 21k98% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- release-publishingSkill
- skill-gap-auditSkill
- skill-maintenanceSkill
- meteor-accountsSkill
- meteor-blazeSkill
- meteor-cli-installationSkill
- meteor-community-packagesSkill
- meteor-debuggingSkill
- meteor-deploymentSkill
- meteor-methodsSkill
- meteor-modern-build-stackSkill
- meteor-mongo-minimongoSkill
- meteor-nativeSkill
- meteor-pubsubSkill
- meteor-reactSkill
- meteor-securitySkill
- meteor-testingSkill
- migrate-to-meteor-3Skill
- migrate-to-rspackSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 45
Do not infer that an app is checked because meteor run or meteor build succeeded.
- Distinctive: line 62
Read declaration providers for the ordered switch, native adapter/barrel distinction, inherited configuration, TypeScript 7 compatibility, …
- Very specific: line 72
Use the app's local compiler.
- Very specific: line 75
Check tsc --listFiles --noEmit includes application source.
- Very specific: line 83
Keep generated .meteor/types/ untracked and unedited.
- Distinctive: line 98
If the actual task is publishing package declarations, use the official Atmosphere package types documentation.
- Distinctive: line 100
Do not edit generated application adapters as a package-authoring solution.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 declarations start with 3.6-beta.1; this workflow is verified through 3.6-beta.3 and against the 3.6-rc.0 source. Beta.3 adds the declaration corrections linked below; the RC retains explicit generation and provider choice.
| Target and intent | Decision |
| Meteor 3 before 3.6-beta.1 | Native meteor types is unavailable. Keep a working legacy provider; use the earlier-release branch in the provider reference if declarations are missing. |
| New or existing 3.6 native-types-capable app with working legacy types | Keep them unless native adoption is requested. Beta.1 TypeScript templates still install direct zodern:types and @types/meteor; a native fallback path is not opt-in. |
| Explicit native adoption on 3.6-beta.1 through beta.3 or 3.6-rc.0 | 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 beta 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
- Confirm generation actually ran. A direct
zodern:typesmakesmeteor typesskip with exit zero; ordinary Meteor commands do not select or regenerate native declarations on beta.1 through beta.3 or the RC. - Use the app's local compiler. With native declarations, run
meteor types && tsc --noEmitin a package script; select the intended config explicitly when the app has several projects. - Check
tsc --listFiles --noEmitincludes application source. Appending a barrel underfilescan 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 enablecheckJs; select JS checking separately when requested. - 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.
- Keep generated
.meteor/types/untracked and unedited. Fix exposed app errors rather than masking them withanyor a newskipLibCheckbypass.
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. |
| 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 beta.3 declaration corrections 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.