Looking for help migrating packages to Meteor 3.0

3.0 migration
24

I think you should publish those packages one way or another. I’m most interested in useraccounts:* & kadira:blaze-layout. useraccounts is one of the reasons that made Meteor click for me and it was a joy to spin up application with full blown authentication. How different is your blaze-layout fork to GitHub - trychlos/pwix-blaze-layout: Layout Manager for Blaze (works well with Meteor FlowRouter) ?

25

I’m glad to hear that you are still using useraccounts:*. I thought I’m the only archaeologist digging up these old packages. I agree, they are pretty capable, and so easy to extend, via config or directly in the code. I will send pull requests for three of them that I forked to the Meteor Compat organisation.

blaze-layout is actually a fork of pwix-blaze-layout, but I prefer to keep it under the kadira namespace, as I assume more users will have that included in their packages. But I could send the pull request to pwix-blaze-layout instead, if that’s what people are using nowadays.

26

I’m glad to hear that you are still using useraccounts:*. I thought I’m the only archaeologist digging up these old packages. I agree, they are pretty capable, and so easy to extend, via config or directly in the code. I will send pull requests for three of them that I forked to the Meteor Compat organisation.

These packages are what ignited my love for Meteor and I believe they’re also the key to the future. If developers try out these packages they too shall develop the same appetite for Meteor.

Can’t wait to see your pull requests not just for useraccounts:* but for the packages you’ve migrated :+1:

27

Moar updates

Things are moving pretty fast on the community packages, hopefully all lose ends are tied by the end February as promised.

We’d appreciate if someone can step up and work on Migration 3.0 by klablink · Pull Request #13 · Meteor-Community-Packages/redis-oplog · GitHub
as @storyteller has his hands full now

3 Likes
28

Hi @storyteller, just a clarification, in the latest release of meteor-collection-hooks it is listed as compatible with Meteor 3 even though the tests do not work, as indicated, and async logic is not implemented, what does it mean to have included in the supported versions 3.0-beta.0?

29

A quick update from us.
As of now, the following have pull requests submitted:

reywood:publish-composite # Awaiting review from MCP maintainers
tmeasday:publish-counts # Awaiting review from MCP maintainers
deanius:promise # Pull request merged, but current maintainer says it won't publish anymore
useraccounts:core # Pull request sent to Meteor Compat Packages
useraccounts:bootstrap # Pull request sent to Meteor Compat Packages

Update 2:

coagmano:stylus@v1.1.3 # Pull request submitted to MCP
coagmano:stylus@v2.0.3 # Pull request submitted to MCP

Update 3:
(Discussion: Feedback needed: simple:rest compat - #8 by illustreets)

json-routes@v3.0.0 # Pull request submitted to Meteor Compat Packages
rest-json-error-handler@v1.1.3 # Pull request submitted to Meteor Compat Packages

Update 4:

pwix:blaze-layout@v2.3.2 # Pull request submitted to current maintainer
2 Likes
30

Okay, so far I submitted pull requests for the bulk of packages that we migrated to, or otherwise made compatible with, Meteor 3.0.

I am confident that the ones under the Meteor Compat Packages and MCP umbrellas will be merged sooner or later. I hope pwix:blaze-layout is still maintained, so they merge the pull request, which is quite tiny actually.

However, we have a few upgraded packages that I’m not entirely sure what to do about:

  • deanius:promise - Pull request was merged by the current maintainer, but he will not be publishing or maintaining it anymore. Read our brief exchange at the pull request link posted earlier in the thread.

  • meteorhacks:ssr - This one looks like is still being used by people who are rendering email templates on the server, to be used with Accounts email methods. Would be good if Meteor Compat Packages took this one under their org.

  • meteorhacks:inject-initial - Useful in a multitude of situations. See the discussion above.

  • meteorhacks:sikka - I am surprised to see that there is little interest in what is to this date the only firewall built specifically for Meteor. The official ddp-rate-limiter is not sufficient to protect against abusive requests. Also, not everyone can, or want, to proxy via Cloudflare.

    Maybe Meteor has become so niche that no one is attempting DDP scraping. Well, nevermind …

    Looks like akarda:sikka is the most recent fork (and the only one in 5 years); if nothing else works, I may try and submit it there.

  • useraccounts:flow-routing - This one has dependencies on kadira:flow-router and kadira:blaze-layout. We have an internal fork of kadira:flow-router which diverges from the upstream, and also from ostrio:flow-router-extra. I am not even sure there are many (any?) users of this package to benefit from this effort, so we’ll put the breaks on this one for now.

Speaking of the useraccounts.* namespace, now that the core package has been upgraded and the OAuth support fixed, it may become useful to a wider audience. Maybe someone can pick up useraccounts-unstyled, useraccounts-iron-routing, and useraccounts-flow-routing-extra.

We would have spared the effort, but 1) none of these packages has tests and 2) we do not use any of them, so we are not familiar with their codebase and usage. I’m happy to assist / contribute if someone else can work with us to test the changes, as we won’t touch the code without knowing how it is supposed to work

2 Likes
31

Given your comment. I’m now led to believe that the 3.0 might have a good upside with so many packages being updated and revived.

  • useraccounts:flow-routing - This one has dependencies on kadira:flow-router and kadira:blaze-layout. We have an internal fork of kadira:flow-router which diverges from the upstream, and also from ostrio:flow-router-extra. I am not even sure there are many (any?) users of this package to benefit from this effort, so we’ll put the breaks on this one for now.

Speaking of the useraccounts.* namespace, now that the core package has been upgraded and the OAuth support fixed, it may become useful to a wider audience. Maybe someone can pick up useraccounts-unstyled, useraccounts-iron-routing, and useraccounts-flow-routing-extra.

If you think the changes you’ve have are too awkward for mainstream audience of the package you may publish it under your own namespace. Monti APM published its own version of GitHub - monti-apm/flow-router: Carefully Designed Client Side Router for Meteor and bee-queue.

32

I believe that too. Meteor is not only shedding a good chunk of the legacy, but also indirectly overhauls the packages ecosystem.

The ones that make it past this stage must be really important, so there’s that, it’s almost like a community survey :laughing:

That’s great, I had no idea it exists. Our fork has stuff that, to be honest, can be monkey-patched on the FlowRouter object, if it’s still implied, so I will check that for our internal use - it’s mostly for base64 encoding parameters and other exotic functionality, some pull requests that Kadira never merged, nothing unusual.

But on the subject of useraccounts:flow-routing, its dependencies should then be updated to maintained forks, irrespective of what illustreets needs in-house. I can easily update the fork’s dependencies to montiapm:flow-router and pwix:blaze-layout and send a pull request. The latter, only if they merge my pull request. If not, maybe I can coax @storyteller or @filipenevola to accept our kadira:blaze-layout, updated an compatible, under Meteor Compat.

33

I don’t have anything to do with that, so the only thing I could do is annoy other people about it. I think Meteor Software manages those repositories and has the option to publish those packages.

34

I understand, thanks! I will first attempt to find an active maintainer outside Meteor Compat.

35

:alarm_clock: :alarm_clock::alarm_clock: Time for some new updates

  • Instead of migrating xolvio:cleaner, I opted to pull out the resetDatabase function and asyncify it. Here’s the code for it, in case someone needs it:
export const resetDatabase = async function (options = {}) {
    if (process.env.NODE_ENV !== "development") {
        throw new Error(
            "resetDatabase is not allowed outside of a development mode. " +
                "Aborting."
        );
    }

    let excludedCollections = ["system.indexes"];
    if (options.excludedCollections) {
        excludedCollections = excludedCollections.concat(
            options.excludedCollections
        );
    }

    const db =
        options.db || MongoInternals.defaultRemoteCollectionDriver().mongo.db;
    const collections = await db.collections();

    const appCollections = _.reject(collections, function (col) {
        return (
            col.collectionName.indexOf("velocity") === 0 ||
            excludedCollections.indexOf(col.collectionName) !== -1
        );
    });

    for await (const col of appCollections) {
        await col.deleteMany({});
    }
};

Please start out trying the beta packages and report any problems you find.

1 Like
36

@harry97 Thanks for mentioning :wink: Got a local copy of an async version of meteor-push running on 2.14 with no async warnings.

37

BTW @harry97 I even forgot the Beta code of meteor-push was already updated with async functions a couple of months back :joy:

38

Yeah, that saves us a great chunk of time already :laughing: couldn’t you say that earlier.

EDIT: Can you start a PR with that branch and release a beta version to atmosphere so we can test things out?

39

I wrote a blogpost about my latest OSS endeavors regarding Meteor 3.0 packages migration.

Thanks to Daniel & Trusted Care I was able to migrate many packages to async that we use in our application:

3 Likes
40

Hello guys, long time no see. There has not been much going on lately but there’re few things I’d like to draw your attention to:

  • Async migration by harryadel · Pull Request #112 · msavin/SteveJobs · GitHub - I’ve been working on updating this package, please give it a go and let me know if you run into any issues.
  • Add Meteor 3.0 Compatibility by harryadel · Pull Request #1 · itgenio/meteor-persistent-session · GitHub - If you’ve been using any of Cult of Coders Persistent Session, then I’d recommend that you switch over to @afrokick fork, they’ve already solved most of the conflicts and only needed a little push.
  • Simple Schema Async Compatibility - As it currently stands, simple schema isn’t async friendly as nearly all the computed fields/values can’t run async operations. I’ve tried to get my hands dirty with it but any simple async change bubbles up and forces you to modify the entire package. It’s not a simple task and requires time which I’m unable to dedicate right now. @jkuester will be able to dedicate time for it in the near future so please if anyone has sometime let us know so we can coordinate it. Sames goes for Autoform, it also needs some serious work. Simple Schema / Autoform / Collection 2 - the trifecta, all work in harmony and currently only collection2 has been migrated to async.
2 Likes
41

I never wanted to comment on this, but for what it’s worth, here is my opinion: schema checks, whether in Meteor/MongoDB or any other system, should not involve async calls to HTTP endpoints or to the database. Just think about a schema check on an array of items, what if you have a custom function hitting the database for each item? In 12 years working with Meteor it has not occurred to me that one could/should be going for this kind of approach. Gee, Simple Schema, while great, is enough of a slow hog as it is.

I personally see it as a great ergonomic adage, made possible back in the day because of the synchronous isomorphic code / Fibers everywhere / “so why not” kind of thinking. Which, I assume, led many to use this pattern. But maybe it’s one of those things that should now be left behind.

While I can see why and where it would be useful, it looks like an antipattern and maybe it should be highlighted as such; if these async calls are indeed required, maybe they actually belong to a different layer (authorisation, for instance). But that is just me, and likely I don’t have the full perspective on why this is a good idea.

Anyway, a more useful question is: would some extra sponsorship/funding help move things forward, whatever the decision regarding Simple Schema?

2 Likes
42

Deciding to move a “validation” to another part of your code because it is async or not is not really about being good pattern or anti pattern or good thinking - in simple terms, it is called a tool/library/framework limitation.

[Addendum]

43

I should have made it clear that my point was in reference to using Simple Schema in conjunction with Collection2. In this case, I stand by what I said: it is an antipattern to make async calls while schema checking a document about to be inserted or modified in said MongoDB. If you can point me to a database system allowing this pattern as standard, I will stand corrected.

The rest of use cases, where Simple Schema is used for validating method arguments and other such use cases, yes, I have no comment there, though personally I avoid that too.

Nothing changes the fact that Collection2 is now being held back unnecessarily.

1 Like