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

permb · May 8, 2024, 8:41am

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:

github.com

Meteor-Community-Packages/meteor-typescript/blob/master/package.js

const COMPILER_VERSION = "0.5.0";
const TYPESCRIPT_VERSION = "5.4.5";
const MY_VERSION = COMPILER_VERSION; // Keep in sync

Package.describe({
  name: "refapp:meteor-typescript",
  version: MY_VERSION,
  summary: "A Typescript compiler plugin for Meteor",
  git: "https://github.com/Meteor-Community-Packages/meteor-typescript",
  documentation: "README.md",
});

Package.registerBuildPlugin({
  name: "meteor-typescript",
  use: ["refapp:meteor-typescript-compiler@" + COMPILER_VERSION],
  sources: ["meteor-typescript-plugin.js"],
  npmDependencies: {
    typescript: TYPESCRIPT_VERSION,
  },
});

This file has been truncated. show original

harry97 · May 8, 2024, 9:29am

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

github.com/meteor/meteor

Document --release option on meteor publish command

opened 11:16PM - 08 Jan 24 UTC

jankapunkt

confirmed good first issue missing-docs

Using Meteor 2.14 I can enter `meteor publish --help` which gives the following …documentation: ``` Usage: meteor publish [--create] meteor publish --update Publishes a new version of a local package to the package server. Must be run from the directory containing the package. Reads the package.js file for version information, builds the package and sends both the package source and the built version of the package to the package server. This will create at most one build of the package. If the package has an OS-dependent binary component, publishing will only register metadata about the package. The binary component will be compiled when it is installed into an application with `meteor add`. To pre-build a package for a particular platform, use the `meteor publish-for-arch` command. This will mark you as the only maintainer of the package. You can use 'meteor admin maintainers' to change package maintainers. For more information about admin commands, run 'meteor help admin'. Change the metadata for a given version of a package by running with the --update flag. That will set the git url, version summary, longform description and documentation in the database to their new values. You can use 'meteor show' to preview the results. Pass --create to create a new package. Options: --create publish a new package --update changed metadata of a previously published version --allow-incompatible-update Allow packages in your project to be upgraded or downgraded to versions that are potentially incompatible with the current versions, if required to satisfy all package version constraints. --no-lint don't run linters on the published package and its local dependencies before publishing ``` However, I didn't know that I can actually use `--release` here in order to resolve "top-level" version conflicts, which was recently a big blocker when attempting to publish packages for 3.0 beta. This option should be added to the help and maybe also to the migration docs. Might be crucial for people who struggle with migrating packages.

permb · May 8, 2024, 9:45am

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…

harry97 · May 8, 2024, 9:58am

@jkuester @zodern can maybe help us here

zodern · May 8, 2024, 5:39pm

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:

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.
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).
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.

permb · May 8, 2024, 5:52pm

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?

zodern · May 8, 2024, 5:57pm

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

permb · May 8, 2024, 6:28pm

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 !