Fibers Public Roadmap and Meteor 3.0

announce
62

Thanks for clearing it up. I’m trying to figure out what to report this week on MeteorJS Dispatches. That is, looking for what the build will be that they can download. Expecting 3.0-alpha.13 or something similar…

63

I appreciate all the work that everyone in the core team is doing to handle the release of Meteor 3.0. At the same time, I love the loyalty and commited community based on the love for the tool. The open to speech and proactive spirit define us on our endevors to keep using Meteor in our daily basis, whether it’s in the form of personal usage or through invaluable contributions such as packages and enhancements. We should not lose the focus on that no matter which are the circumstances and reactions around us.

I am excited and motivated on Meteor 3. I started to use it locally. In fact, I wish go further and start provinding some adaption to community packages, to not use fibers anymore.

I created a small app using Meteor 3, and I realized that tests are not working properly. We are missing the adaption of test packages there. Tests are an essential part to adapt the rest of packages, since almost all them involve to run tests to verify the behaviors are still working.

I did some changes on test packages to be fiber-free and I was able to pass properly the tests for an example app as you can see in the picture below.

image
image1840×563 113 KB

with browser driver

I am not sure if it will cover all scenarios. Surely, there is more to adapt, like test coverage and may others, this is just a start. But the simple test capability may be adapted with a minor change I could commit for review.

My questions are:

  • Is anyone already in charge of the testing part? Is it planned or already tackled by the core or any community member?
  • How would the procedure be to start contributing with the changes on the packages?

I believe these are the next steps to define in order to get more people involved on this migration.

8 Likes
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?