Meteor 3.1.x, Express and third party libraries

help
1

Dear all,

We’re in the process of upgrading our Meteor 3.0.4 platform to the latest Meteor release (3.2 hopefully).
I see that Meteor, starting from v3.1, updates its Express dependency to Express v5.

Our application is using an external node module (ltijs) that still relies on Express v4 for its internal workings.
I do wonder if this can be a problem. Can the 2 Express versions coexist if we hold on the upgrade of the third party library for the moment? Or is this going to cause issues?
I guess my main question is: with a third party library pulling in Express v4 in the project node_modules folder, is Meteor internally still able to use Express v5 as per its package dependencies? or will it be somehow affected?

1 Like
2

Meteor internally still able to use Express v5 as per its package dependencies?

Yes!

What will probably happen is that your app and node packages will use the v4 version, and meteor-packages-related code will use the v5 version.

I would test it a bit just to be sure. (it has been a while since I do not had this kind of issue)

Let me ping @nachocodoner to see if he has ever had this issue before

3

Thank you @grubba , it’s super appreciated.

Though, we have a fork of the third party library we depend on (ltijs) and we’ve just patched it so to bring it up to Express v5 (the main issue was around the usage of express.options("*", cors()) and so far things seem to be working fine after the patch :crossed_fingers:

4

I haven’t encountered this myself, as I usually ensure everything is properly migrated when upgrading.

However, what I can say is that, Meteor includes a built-in version of Express within the webapp package, placing that dependency outside the app’s npm context. If your app also depends on Express, directly or indirectly, that version is preserved. Besides, Node’s module resolution allows multiple versions of the same library to coexist at different levels in the node_modules tree. This means you can use two different versions. In this scenario, ltijs sets up its own Express server and version for its specific needs.

Anyway, always make sure to test the basic coverage at a minimum.

1 Like
5

I know Express 5 introduced breaking changes, and I’m not sure if ltijs will need adjustments to support that version. If they make full of Express usage it likely need migrations.

It might be safer to verify whether Express 4 and 5 can coexist without issues. I can’t think of any immediate reasons they wouldn’t.

Regardless, let us know how the process went.

6

Thanks for your advice @nachocodoner, super appreciated!

Having a clean upgrade path is also our target so we’re actually heading that way. We’ve already forked ltijs and patched it (as noted, it seems the only real breaking issue was the use of the express.options() call with the catch-all wildcard “*”). We’ve also submitted a PR to ltijs so as soon as they do the same on their part we’ll be able to abandon our fork.
So far all of our use-cases seem to be working fine without any issue so my guess is that the upgrade path to Express v5 is actually pretty smooth :crossed_fingers: