(SOLVED) Is it possible to publish a meteor compiler package that works for both 2.0 and 3.0? (YES!)

After running the same source code compiler package (linked via ./packages) with Meteor 2 and 3, I thought it would be fine to just publish one version of refapp:meteor-typescript, but then when I tried to use the published version in a project upgraded to Meteor 3, I got this error:

  While loading plugin `meteor-typescript` from package `refapp:meteor-typescript`:
   packages/modules-runtime.js:222:12: Cannot find module 'fibers'
   at makeMissingError (packages/modules-runtime.js:222:12)
   at Module.require (packages/modules-runtime.js:241:17)
   at require (packages/modules-runtime.js:258:21)
   at module (packages/promise.js:41:7)
   at fileEvaluate (packages/modules-runtime.js:336:7)
   at Module.require (packages/modules-runtime.js:238:14)
   at require (packages/modules-runtime.js:258:21)
   at packages/promise.js:149:15
   at packages/promise.js:156:3

This suggests that something inside the published package (these are packaged differently for isobuild packages compared to “normal” packages) still has Meteor 2 fibers stuff embedded.

Can someone from the Meteor team please document somewhere (or point to existing documentation) how to publish compiler/isobuild packages for 3.0. Is dual-mode publishing possible? If not, can you fix it so that it becomes possible?

package.js for the compiler:

Did you use the --release option to set the specific Meteor version you’re “releasing” your package for?

Hmm no that never occurred to me…

Can I publish the same package version twice then? Once with --release 3.0-rc.1 and once with --release 2.12?

Or do they need separate version numbers? If so, I would need separate branches with different versions in package.js anyway and then I could just have api.versionsFrom with 2.x vs 3.x in the branches…

@jkuester @zodern can maybe help us here

All of my build plugins that I’ve updated to support Meteor 3 also support Meteor 1 and 2 (some back to Meteor 1.4).

We can categorize build plugins in three groups:

  1. build plugins that have no dependencies. These are simple - if the plugin code doesn’t use fibers, then they should work in Meteor 3. The package zodern:meteor-package-versions is an example.

  2. build plugins that depend on some packages, but does not directly or indirectly use ecmascript or other packages that use fibers. In this case, the only package that uses fibers should be the meteor package, which is always part of the build plugin if it has any dependencies. Meteor 3 provides a stub of fibers to the meteor package, so as long as you don’t use any of the meteor package’s api’s that use fibers, it should work in Meteor 3. My package zodern:types fits in this category, and supports Meteor 1.4 - Meteor 3 (it’s actually published using Meteor 1.4 to make it easier to support older Meteor versions).

  3. any other build plugin, including those that use ecmascript or babel-compiler. When a build plugin is published, Meteor includes a copy of all of its dependencies from the current Meteor release, and compiles the package. This is different from normal packages that are instead compiled as part of an app. For a build plugin to support Meteor 3, it needs to use the updated core packages from Meteor 3. This is possible using meteor publish --release <Meteor release>. zodern:melte is published this way, and has been tested with Meteor 1.8.1 - Meteor 3. We put in some effort in Meteor 3 to ensure the core packages commonly used in build plugins will work in older Meteor/Node versions.

Thanks for the detailed info.

So if I understand you correctly, I can publish my compiler which inherits from BabelCompiler using —release 3.0-rc.1 and it will work in both meteor 3 and meteor 2?

Yes, if you publish with Meteor 3 it should still work in Meteor 2.

1 Like

I just published v0.5.1 of refapp:meteor-typescript using meteor publish --release 3.0-rc.1 and can confirm that it now works with both Meteor 2 and 3 from atmosphere.

Thanks again @zodern !

1 Like