Looking for help migrating packages to Meteor 3.0

3.0 migration
13

Thank you @harry97 for your good work! At least I hope so, I didn’t check the PR yet! :smiley: But I have faith in you!

Thank you for helping out with the packages migration! Amazing work so far zoomer! :stuck_out_tongue:

1 Like
14

Another day, another update.

3 Likes
15

I am writing this comment to try to solve a package migration problem. In this regard, I started a discussion about changing the way packages are loaded, which makes some important libraries unusable for the time being. In my case: redis-oplog, lai:collection-extensions, mongo-collection-instances. In particular, all libraries that for some reason need to overload the collections constructor. The bug is tricky in that it can work in some cases, depending on when the package is loaded.

I would like to know if any of you have encountered this problem and if you have found a solution. Currently this problem makes it impossible to migrate my applications.

16

We had issues with a couple of monkey patches for Mongo. The patches are related to indexing, so kind of have to be used when the app starts. In our case, putting the code using the patches in Meteor.startup(...) solved the issue. But that’s only one use case.

Perhaps, with lai:collection-extensions, and mongo-collection-instances, consider loading them in a dedicated internal package, let’s call it pbeato:mongo, and export Mongo from it (those packages already load mongo by themselves). Put pbeato:mongo at the top of the packages file, and also import { Mongo } from 'meteor/pbeato:mongo' in whatever package/module you need it.

17

Cross posting here from Large SaaS migrated to 3.0.

We forked locally and migrated a bunch of packages:

aumel:security-authorization
storyteller:cdn
reywood:publish-composite
meteorhacks:meteorx
meteorhacks:sikka
meteorhacks:inject-initial
simple:json-routes
meteorhacks:ssr
coagmano:stylus #(Only v1, because we need cross-package imports but v2 is also relatively easy)
useraccounts:*
kadira:blaze-layout

Some, like aumel:security-authorization, may not be everyone’s cup of tea, and unless the maintainer accepts a pull request, we’ll just keep it as a local fork.

Looking to contribute the changes to reywood:publish-composite, coagmano:stylus, and storyteller:cdn to the respective repositories, because they are still maintained.

However, what is to be done with the rest? Some, like simple:json-routes and useraccounts:* are under Meteor Compat Packages · GitHub, so I’m not sure there is anyone available to merge our pull requests there.

The kadira:* / meteorhaks:* packages - their maintainer is long gone, and these packages have been forked countless times. I am not keen on contributing further to this fragmentation, thus it is preferable that we do not put them under the illustreets namespace. So, I’m looking for ideas here. They are very useful, and like in the case of sikka, uniquely useful. Hopefully Meteor Community · GitHub would like to take at least some of them under their umbrella, and we will continue to maintain them for the foreseeable future.

1 Like
18

Some good news on this one. Our changes have been merged into this pull request: Update tests by StorytellerCZ · Pull Request #173 · Meteor-Community-Packages/meteor-publish-composite · GitHub. It is awaiting review and hopefully will be published soon.

tmeasday:publish-counts

A package often shunned because of performance issues with large collections (but that is just simply misuse!), otherwise very helpful in a multitude of use cases. We just submitted a pretty big pull request here: Meteor 3.0 compatibility by manueltimita · Pull Request #99 · percolatestudio/publish-counts · GitHub. The repo still looks maintained, so hopefully it will be merged soon.

deanius:promise

Another package that seems to be still maintained (@storyteller’s pull request from 2 months ago got merged). We also submitted a pull request there, for compatibility with Meteor 3.0: Compatible with Meteor 3.0 by manueltimita · Pull Request #35 · deanrad/meteor-promise · GitHub

2 Likes
19

Unfortunately I cannot upgrade activitree:push until we get a buildable version of Meteor 3. Testing requires authorized domains and can only test it in production.
On Cordova side successful mobile builds are also required.

The alternative to activitree:push, as I noticed is using OneSignal or other 3rd parties but they are not GDPR compliant or at least they cannot guarantee confidentiality of messages.

Hopefully Beta.1 or 2 will be deployable to clouds.

20

This one should have now an update that should be fine with Meteor 3 beta.

Merging there is Meteor Software responsibility, so it should be able to get in.

We do have some of them under MCP. inject-initial sounds very similar to inject-data, we’ll have to look into this.

21

This is under Percolate Studios, so that is managed by Meteor Software as well.

22

I maintain montiapm:meteorx, which has been updated for Meteor 3.

1 Like
23

inject-data only has a subset of functionality found in inject-initial, which is injecting data into the HTML sent to the client.

inject-initial on the other hand gives you access to the raw html, head, and body of the page, before being sent to the client, so one can modify the HTML, inject conditional CSS, scripts, and do all kinds of voodoo.

Here is a stripped down overview of the API:

Inject = {
  // stores in a script type=application/ejson tag, accessed with Injected.obj('id')
  obj: function(id, data, res) {
    this._checkForObjOrFunction(data,
      'Inject.obj(id, data [,res]) expects `data` to be an Object or Function');
    // ..
  },

  // Inserts a META called `id`, whose `content` can be accessed with Injected.meta()
  meta: function(id, data, res) {
    this._checkForTextOrFunction(data,
      'Inject.meta(id, data [,res]) expects `data` to be an String or Function');
    // ..
  },

  rawHead: function(id, textOrFunc, res) {
    this._checkForTextOrFunction(textOrFunc,
      'Inject.rawHead(id, content [,res]) expects `content` to be an String or Function');
  },

  rawBody: function(id, textOrFunc, res) {
    this._checkForTextOrFunction(textOrFunc,
      'Inject.rawBody(id, content [,res]) expects `content` to be an String or Function');
    // ..
  },

  // The callback receives the entire HTML page and must return a modified version
  rawModHtml: function(id, func) {
    // ..
  },
};
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.