Meteor Roadmap questions

core
21

Support for Node 12 is ending at the end of this month:

So people should be upgrading at least to Meteor v2.3 which has Node 14:

I think in the future things will have LTS will have to be considered and will probably have to coincide with the Node schedule to some degree.

1 Like
22

node support is not the only problem with fibers.

It basically makes meteor a non-standard javascript environment. While it initially was a bless for isomorphic apps (frontend and backend share code), its now a big problem. If you use fiber code in your frontend, you will get problems with server side rendering, because many frameworks like react are not built for non-standard javascript runtimes.

other libraries also suffer from that in a very unexpected and inconsistent way. One example I had was with memoizee which basically memoize functions (store its result so further invocations return a cached result). It breaks with fiber code. Even worse, it breaks very inconsitently.

It may also be confusing for newer devs, because async/await is now the way to deal with that.

Its a challenging situation, because removing fibers means breaking of the classic meteor collections and pub/sub mechanism. It will break nearly every meteor app there is. I think its the better idea to just try to keep it like this, which means maintaining fibers.

4 Likes
23

Iā€™m on version 13.8 - not ideal but not ending (yet)

Iā€™m on Meteor version 2.2 which works. I havenā€™t spend time on checking if there are still some old packages that break but once I have the next big release out I will surely look at it.

Do we have a recommended, stable version of node 14?

1 Like
24

Each version of Meteor targets a specific version of node. That is the version you should be using. See here: Changelog | Meteor API Docs

2 Likes
25

Install it automatically with your CI meteor node -v

1 Like
26

This version is already unsupported (yes, earlier than version 12 which is under LTS). Never use odd-numbered node version in production.

2 Likes
27

Thanks RJ, this is actually my locally installed node version. CodeBuild uses version 12 (Docker image 12.18.0 to be precise). So Iā€™ve got some work to do.

Thanks also to @vooteles for your helpful comments, I see that node 14.19.1 is now the latest as per Meteor version 2.7

28

Its a challenging situation, because removing fibers means breaking of the classic meteor collections and pub/sub mechanism. It will break nearly every meteor app there is. I think its the better idea to just try to keep it like this, which means maintaining fibers.

I think maintaining fibers will be required anyway until the full migration to async hooks is completed and many major projects have migrated, too.

I think this was already proposed in the async hooks roadmap on GitHub in some way.

I am pro moving to async hooks and getting rid of fibers but I totally support your point in the way that the transitions needs to be as smooth as possible for projects relying on fibers.

29

Did someone already check how to make fibers work with Node 16? I donā€™t know the details but I remember the discussion wherein the feature in node being used by fibers has been removed in Node 16

30

Yes thatā€™s most likely what will happen. My understanding from the GitHub issue is that Fiber uses unofficial APIs/behavior and it could be modified /deprecated at any point down the road. Beside, aligning with JS ecosystem is the right step forward since every JS developer needs to learn async/await syntax.

It is a challenging transition for the ecosystem as a whole but itā€™s doable if prioritized and managed correctly.

2 Likes
31

Phase 1.1 here answered this question: Change how Meteor executes Async code Ā· Discussion #11505 Ā· meteor/meteor Ā· GitHub

Although not sure if any tests were done and how far it did progress

32

Making fibers work on node 16 in a Linux environment is quite easy, but there is a substantial performance cost (every fiber requires a new thread)

My biggest concern with switching to async hooks is that it isnā€™t available on the client. While fibers also arenā€™t available on the client, their purpose was to avoid the need of them on the client. If weā€™re moving everything to async await weā€™re going to have a hard time with async calls in client stubs, specifically how meteor on the client side knows that itā€™s currently in a stub and therefore not to call any further methods.

Iā€™m not sure there is currently a solution to this

1 Like
33

Does that issue exist outside of minimingo? I have been using React and a DDP client

I didnā€™t get this part, an example would be useful. Iā€™m using DDP client with React and async/wait in methods calls already so that is not an issue for me. But I suppose you referring to minimongo/Blaze? what would be an example of what you are saying?

1 Like
34

Minimongo DB updates are certainly the most common cause of this. However, a trivial example:

// lib.js (present on both client and server)
function somethingActuallyAsync() {
    return new Promise((resolve) => setTimeout(resolve, 100));
}
Meteor.methods({
  async thing() {
     await somethingActuallyAsync();
     Meteor.call("whatever");
  }
})
Meteor.call("thing");

This will result in calling whatever twice, once initiated by the server, once from the client. The reason for this is that meteor blocks calling of methods from the client stub with a Meteor.EnvironmentVariable which assumes a synchronous environment (specifically DDP._CurrentMethodInvocation.get() called in livedata_connection.js).

If all your methods are defined only on the server, or you have entirely different definitions on the client vs the server (and the client definitions donā€™t use await), then youā€™re fine.

A lot of these problems could likely be solved by having very disciplined use of Meteor.call ONLY from the client - e.g., not having reusable modules defined as meteor methods at all - and instead extracting to functions. This is fairly standard best practices anyway - but for large legacy applications, this migration will be substantial.

5 Likes
36

Thatā€™s how Iā€™ve been using it. If you use GraphQL or DDP client (like SimpleDDP) this wonā€™t be an issue. But I understand this will be an issue with isomorphic code.

Either way, I think migrating off Fibers while maintaining it as long possible is the path forward. Meteor is one of earlier NodeJS frameworks and this is needed to keep it up for years to come.

37

Havenā€™t used Meteor in several years and was considering trying it out again. Looking at the Roadmap, Iā€™m surprised to see on that Meteor is still apparently quite behind on some key JavaScript features?

  • no ES Modules
  • no tree-shaking
  • no top-level await
38

Tree shaking:

Top-level await:

ESM:

6 Likes