Fibers Public Roadmap and Meteor 3.0

announce
64

It is part of the Beta Roadmap: Fibers Public Roadmap - Meteor 3.0 · GitHub

@hschmaiske might give a better answer on this

65

As rjdavid said, it’s part of the roadmap, but you could definitely help.

Even if you don’t have everything ready right away, you can open a draft PR against this branch with a detailed description of what you’re doing and a checklist of what’s missing.

If you need any help, you can also DM me on Slack.

2 Likes
66

Hello everyone, quick bi-weekly update:

Here are the latest updates on the successfully completed tasks:

  • New alpha version - You can create a new app with this version by running meteor create --release 3.0-alpha.15 myapp
  • Review major/minor version of packages - we reviewed all the packages and rolled back the versions that didn’t need to be updated.

Currently, we are actively working on the following tasks:

  • Fix problems with our tutorials when doing them with Meteor 3 - we’re extensively testing our Alpha version right now to make sure we can refine it more before a Beta version. We already found simple bugs, like Cursor.count() not working properly. So we want to tackle those types of bugs first before releasing a Beta.
  • More will be started in the next few days

You can follow the updates on our Fibers Public Roadmap and on this Github PR

13 Likes
67

I heard that in Meteor 3.0, we will use express server and remove connect package. Is that right?

68

That’s right @minhna! If you have any concerns, there is a topic with some discussion around it.

2 Likes
69

Hello everyone! Here is a small update:

Some tasks we’ve been working on it:

Our plan for the next week is to release one more Alpha, which will include changes like this one and this one.

After that, we’ll address the issue Unhandled Rejection when fails to bundle the app as well as more issues our community is reporting, like this one.

See you soon for more updates!

You can follow the updates on our Fibers Public Roadmap and on this Github PR .

10 Likes
70

Hi everyone! First of all, I want to say thanks for the effort updating Meteor to V3 which is a huge change and we really appreciate.

Currently we’re using Meteor v2.13.3, and lot’s of libraries are forcing us to update to node >= 16 at least, and I’m really worry about this, because our apps are getting outdated since we can’t safely upgrade our libraries. And I think that use meteor 3.0-alpha.17 on production is discouraged since it’s just an alpha version.

I can’t see any deadline for a stable Meteor v3 release. Do you have any deadline on mind?
Do you have any suggestion for people that want to use a more recent Node version and minimize the errors on production?

Thanks for your time!

5 Likes
71

While that’s something only the core team can give you a definitive answer. You can follow the progress of 3.0 migration by following this thread and the official project board on GH.

Also, since you’re on 2.13.3 you should not wait for 3.0 to be officially released to start working you can already start migrating your applications today as the alpha is already out and provide feedback for the core team.

1 Like
72

Hi Harry! Thanks for your reply.

You can follow the progress of 3.0 migration by following this thread and the official project board on GH.

I was already checking it since a few months, but it doesn’t help me to estimate if it will take 4 months, 6 months or even more to have a stable production version, and all other libraries are pushing us to upgrade in the meantime since we’re running on outdated versions.

you should not wait for 3.0 to be officially released to start working you can already start migrating your applications today as the alpha is already

I know that I should not wait for 3.0 to be officially released to start working on the migration of our applications, but we can’t launch an alpha version into production.

Anyway, sorry if it sounds rude at some point, I really appreciate the whole work that team is doing.

This comment has two main ideas:

  1. Let the community know that we’re also worry about this, because it’s something critical stay using an unmaintained Node version on production.
  2. See if somebody has a good recommendation or workaround for us.
73

It’s cool. I know I’m stating the obvious but it’s the best I can do until a core member jumps in :sweat_smile:

2 Likes
74

What @harry97 is speaking here about is migrating to the new *Async function calls. You can push those already into production with your existing 2.x Meteor app. They are there for forward compatibility. This way you can migrate your app’s methods step by step and then when the time comes for 3.0 upgrade you will have only minimum work on the remaining API changes.

75

Thanks for your reply @storyteller!

Let me see if I understood correctly. So what you say is that is safe release our app without any change with meteor 3.0-alpha.17, since it’s retro compatible, and therefore we will be able to use a more recent Node version on Meteor without breaking anything.

Did I get you correctly?

76

No. Implementing the new Async calls will not make it possible to run on newer Node versions right now. Newer Node versions require Meteor to not use Fibers anymore and this is done in Meteor 3. What those Async call allow you to do is to execute some of the migration work right now while you are on Meteor 2.13, so that when a stable version of Meteor 3 ships you’ll have less work to do. At least that seems to be the plan.

77

This isn’t easy. In one project, we have around 20 npm packages that cannot be updated because of node 14. For a few packages with severe security issues, we were able to find alternatives. But tracking becomes a lot more difficult when the dependencies of those packages are the ones with security updates.

78

Thanks for the clarification @vooteles. But as @rjdavid mentioned the major issue here are the rest of packages that can’t be safety updated due to this limitation. We’re not worry about doing the app migration from Meteor 2.13.x to 3. We’re worry about still using an unmaintained Node JS version on production and the consequences of it.

Thanks everyone, I just wanted to be sure that our concerns were understood and that there was not any workaround for now.

79

Is there a list of the new Async function calls that are already supported in the latest Meteor 2.x with their new names/calling conventions, etc.? I think I’ve seen it months ago.

80

@DanielDornhardt listed them in his document

zecrazygerman
zecrazygerman896×544 58.7 KB

1 Like
81

I have this on the client:

        import {Accounts} from "meteor/accounts-base";

        [.....]

        Accounts.createUser({
            first_name: name_first,
            last_name: name_last,
            email: email,
            password: password,
        }, function (err) {
            if (err) {
                // handle errors
            } else {
               //handle success
            }
        });
    }

Then on the server I have:

Accounts.onCreateUser((options, user) => {
	// do stuff
	return user;
});

Does Accounts.createUser become Accounts.createUserAsync?

And does Accounts.onCreateUser become Accounts.onCreateUserAsync?

82

Hi @charlytalavera, we don’t have an exact ETA for this, but we do have a plan, and the plan is to have this official release in the first quarter of 2024. Things can go wrong, but we’re confident that will be possible. Also, the first beta should be coming at the beginning of December.

As for your question about using Alpha in production, we do not recommend that yet, but you can certainly follow the recommendations everyone gave you above and start migrating your app to use the new async methods. This will save you time in the future.

1 Like
83

As for the current version, you have both. So you can keep on using Accounts.createUser.

Accounts.onCreateUser does not need an async version, as it just receives a callback to be called whenever a new user is created.

2 Likes