Packages migration version 3.0-alpha

help
1

I wanted to begin the migration to version 3.x of the packages needed for our application, and in doing so I decided to start with the redis-oplog. The first problem I encountered into was creating a meteor project with the command:

meteor create --release 3.0-alpha.11 test-alpha-11

the result was the error

Error: incorrect data check
at Zlib.zlibOnError [as onerror] (zlib.js:187:17)
=> awaited here:
at Promise.await (/Users/xxxx/.meteor/packages/meteor-tool/.2.13.0.g2b9s0.q37s++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:60:12)
at Object.extractTarGz ....

Seeing that the problem seems to be related to the use of meteor-tools 2.13.0, I tried reinstalling meteor using the command:

curl https://install.meteor.com/\?release=3.0-alpha.11 | sh,

After this the creation of the application was successful, but I clearly lost all the cache of previous versions of meteor. Is this the desired behaviour?

Once the creation was complete, I put the sources of the redis-oplog in the packages directory and tried to launch it, but I get the error

While selecting package versions:
error: Conflict: Constraint aldeed:collection2@3.0.0 is not satisfied by aldeed:collection2 0.1.7.
Constraints on package "aldeed:collection2":
* aldeed:collection2@3.0.0 <- local-test:cultfcoders:redis-oplog 2.2.1

Conflict: Constraint reywood:publish-composite@1.7.3 is not satisfied by reywood:publish-composite 1.3.6.
Constraints on package 'reywood:publish-composite':
* reywood:publish-composite@1.7.3 <- local-test:cultfcoders:redis-oplog 2.2.1

Conflict: Constraint alanning:roles@3.5.1 is not satisfied by alanning:roles 1.0.6.
Constraints on package 'alanning:roles':
* alanning:roles@3.5.1 <- local-test:cultfcoders:redis-oplog 2.2.1
....

The syntax within package.js seems correct to me.

api.use('aldeed:collection2@3.0.0');
api.use('reywood:publish-composite@1.7.3'); 
api.use('natestrauser:publish-performant-counts@0.1.2');

Am I doing something wrong or is it not yet time to start migrating generic packages? Has anyone already experienced something like this?

Thanks.

2

Just tagging people here who I believe are thinking to do something about redis-oplog and meteor 3: @storyteller @filipenevola

3

As @denyhs pointed out, the create command does not work on macs, I think, but I am not sure, that the problems with the version of the packages could be due to the same error, @denyhs do you confirm my hypothesis?

4

This cascade of dependencies will be hard to deal with, but if you want just to test, you can use all of them as local packages, so it should work as they will use the version of your local Meteor app.

If they don’t work, you can just add the version in the package.js.

Your problem here will be with packages not compatible in runtime with Meteor 3.

For example, collection2, I don’t see any commits about Meteor 3.

My goal with the effort that I’m starting is to discover the incompatibilities and start to provide PRs or alternative packages.

As Quave has many packages and apps, if we can make our apps work with Meteor 3, that will help many other companies as we use Meteor quite a lot.

But again, this work will take weeks, if not months, because there will be cases where the package changes will be challenging.

We are starting with our template, which is an almost empty Meteor app (template).

1 Like
5

Please file an issue if you encounter problems, I currently have to wrestle with Google as I missed the deadline for the new min. target API for Android apps is bumped to 33 :dizzy_face: However React Native and Expo updates crashed my builds… :frowning:

Once I’m through with this I can get back to community packages :heart:

1 Like
6

@jkuester @filipenevola, for you information, I completed the migration to Meteor 3 of the collection2 and redis-oplog packages locally. Unfortunately, I cannot do a PR yet as it would fail the build as the dependencies are still not properly resolved. It is still not clear to me whether the packages will have to remain compatible with the fibre version as well or we can overlook it.

1 Like
7

The goal is to first release a backward compatible version if possible that will allow you to migrate to *Async methods (and do upgrade in Meteor 3 alpha/beta/rc) and then release a major version for the final Meteor 3 release.

1 Like
8

This is cool.

I believe you should open a PR anyway so people can try locally as well and suggest changes if necessary.

9

Hi @filipenevola, First, I’m trying to convert Collection2 for version 2.1x.x to support async methods only, as @storyteller indicated, but I’m having some problems with this asynchronous Meteor function generation mode:

ASYNC_COLLECTION_METHODS.forEach(methodName => {
  const methodNameAsync = getAsyncMethodName(methodName);
  Mongo.Collection.prototype[methodNameAsync] = function(...args) {
    try {
    // TODO: Fibers remove this when we remove fibers.
      this[methodName].isCalledFromAsync = true;
      return Promise.resolve(this[methodName](...args));
    } catch (error) {
      return Promise.reject(error);
    }
  };

});

Generates a repetition, instead of saving the methodo name it would have been better to use the function reference. I do not know whether you have already addressed this problem in other libraries. In version 3 it works because the method is a real function of the collection.

Unfortunately, there are so many small differences between the 3 and the others that it is difficult to support everything. I have tried to list here the problems I am encountering.