Types for core Meteor exist both in DefinitelyTyped to add as an npm package, and embedded into Meteor itself.
Using the embedded types requires adding zodern:types to unpack the types into a cleverly built directory in .meteor/local/types.
Except, of course, zodern:types doesn’t support using the core meteor types (as per its readme, where higher precedence is given to the DefinitelyTyped version in the “paths” section, and also this reported and unresolved issue).
Given that zodern:types is also neither maintained by the core meteor team, nor a community package, it seems unwise to me to rely on it. On top of that, the embedded types don’t compile properly (for me).
/Users/per.bergland/.meteor/packages/accounts-base/.2.2.11.1a2x1dl.8xf++os+web.browser+web.browser.legacy+web.cordova/os/packages/accounts-base/accounts-base.d.ts (3,31): File '/Users/per.bergland/Projects/refapp/refapp/.meteor/local/types/packages.d.ts' is not a module.
/Users/per.bergland/.meteor/packages/npm-mongo/.4.17.2.17sxro.2jy9m++os+web.browser+web.browser.legacy+web.cordova/os/packages/npm-mongo/index.d.ts (1,35): Cannot find module 'mongodb' or its corresponding type declarations.
.meteor/local/types/packages.d.ts (49,3): An export assignment cannot be used in a module with other exported elements.
.....
Therefore, I was considering options.
One option would be to just submit PRs to the DefinitelyTyped version for the changes in Meteor 3 (e.g. WebApp) but that would make @types/meteor incompatible with meteor 2.
The other would be to create a new @types/meteor3 package in DefinitelyTyped.
A third would of course be to persuade zodern to support core meteor types and hopefully also move the stewardship over to meteor community or the meteor team.
@zodern is considered a reliable source for packages. So I think improving that package under current ownership is preferred for the short-term.
As for DefinitelyTypes, I think just adding a major version that will have Meteor 3 types is good enough. I would use the same approach as Node has in this matter. Major version tracks the actual major version of Node/Meteor and the rest preferably as well with the exception of patch releases.
The best option would be to move all the types into core and have them be accessible to IDEs out of the box.
Zodern has helped a lot with other work, but this crucial bug which prevents usages of the published types in react-meteor-data has been open since Aug 2023 so maybe the stewardship should be shared?
I now have a working baseline after tweaking the typescript skeleton a little.
It uses a proper typescript compiler (refapp:meteor-typescript) and will use zodern:types also for meteor core types with a pattern to exclude the incompatible ones (react-meteor-data for now) via tsconfig.json.
The project can be updated to meteor 3 and will still compile without errors and work like it should. meteor update --release 3.0.1
I don’t think that follows. Instead I see this as an opportunity for people to submit PRs. The only time when shared stewardship or ownership transfers should come into questions is if the owner is stepping away or the project grows beyond their ability to manage (and in both cases it should be done carefully as XZ and others have demonstrated).
Here is one way to get @zodern’s attention on the issue:
My work is ongoing, but in case someone else is also trying to use the types bundled with meteor 2/3 core packages, you should be aware of some problems and workarounds.
I am attempting to use the bundled types while my app is still based on Meteor 2.16 to make my changes incremental.
react-meteor-data: the bundled types are incompatible with zodern:types, you must use the ones from DefinitelyTyped instead (see GitHub - perbergland/types-problems)