What about atmosphere packages that build on top of Connect? They have to be changed to express too? And why not to keep the rather generic connect* names? Wouldn’t that be more compatible? from MeteorJS Dispatches #3 comments
All REST packages will be affected. The behavior is fortunately very similar as long as no routing is involved. If there is a good test coverage then the biggest issues might be detected immediately.
Might be a good starting point to gather potentially affected packages.
Afaik Meteor Files might be affected as it serves files via http @dr.dimitru ?
1 Like
If possible, we can override each connect* functions to call the new express functions to save effort. New packages can use the new names while keeping compatibility with existing packages
2 Likes
@jkuester thank you for mentioning, Yes I’d strongly oppose any API changes in webapp module. Also I know a lot of project using it for “endpoints” and server-routing. The most liked about webapp.connectHandlers.use is minimal abstraction over native HTTP modules and direct access to request/response streams
The original idea was to keep the same API but using express behind the scene and I think this should be done.
This will work for almost every case as their APIs are still compatible.
@grubba are you opposed to that? I could make this change in my PR about this subject if you are ok.
@filipenevola could you please iterate again on the motivation behind swapping with express? in the PR or here. Thanks!
No! You can change if you want(I think it makes more sense in your PR). We (me and @denyhs ) were discussing making this change along with reverting the bumps. If you want to tackle it, I would not oppose it.
Hey, I believe I explained it here.
TL;DR: Connect is not getting updates, and potentially, it will stop working with popular npm packages like Apollo.
Let me know if something is unclear or if you have follow-up questions.
3 Likes
Make sense, thanks for the effort to keep things up to date, looks like Meteor 3.0 is set to last years ahead 
1 Like
For package like Picker, they will most likely be deprecated as their functionality is covered by Express, which wasn’t the case with Connect (last time I looked into this). So maybe there I will add just one version for compatibility and guide how to use the new Meteor api.
3 Likes
I think this is a good swap and further align Meteor with the rest of JS ecosystem. Express is one the most stable servers and foundation for many frameworks, so it will enhance Meteor story of alignment.
I’m using picker so will be doing that refactor.
2 Likes
Depending on my time I will most likely release a compatibility version so peoe have more time.
After all there is so much to do in v3 if you have a large app.
3 Likes
As a potential workaround for packages that don’t get updated right away, and are still critical to the functioning of an application, a package that patches the Meteor object to assign the new methods to the old method names could be created. You’d just need to make sure it was loaded before all other packages that use the older connect methods to ensure they exist when these packages load.
1 Like
I am of course assuming things based on information garnered from the discussion on this week in meteor, so the idea may need to be modified a bit to make it work but It would basically be a standard monkey patch, assigning WebApp.expressHandlers to WebApp.connectHandlers.
WebApp.connectHandlers = WebApp.expressHandlers;
The assumption here is that Meteor’s underlying API is basically the same and the real change (besides the change from connect to express) is the name of the object connected to WebApp.
The package created for this I believe would need to use api.addFiles in it’s package.js (not api.mainModule), and be moved above any package that uses the older connect API in the .meteor/packages file to ensure proper load order.
Anyone using this method would need to be aware that there is a possibility, however slim, that things may still break due to minor incompatibilities between express and connect. This would allow solving many cases through the simple installation of a package though, and buy some time for those that really need to upgrade to the latest meteor right away, but who also rely on packages that haven’t (and may never) be updated to use the new API.
1 Like
I request that whatever solution we choose (e.g., function override in core or through a package), let us keep exposing the NEW express api. New code can start using the new express api.
That should also make it easy to move from expressjs version 4 to version 5 once it is out (https://github.com/expressjs/express/pull/2237)
1 Like
Hi @copleykj what do you think about this commit?
It is bringing back connectHandlers doing exactly what you said, but instead of expressHandlers we are going to call this handlers (see discussion in the PR).
1 Like
Hi @rjdavid, I didn’t get exactly your concern.
Do you think this PR is not enough?
As you can see, we are still exporting the whole express app, and also keeping the handlers and rawHandlers.
One thing that maybe you want is to also expose the way to create the express app, is that your point?
We could have a function hook for you to override this creation as well and maybe we could include this change in this PR 
1 Like
I’m bumped about this PR, associating Meteor with the most stable JS server library will strengthen Meteor story 10x, it’s just node and express with icing on the cake, that’s easy to deploy and manage.
Good move @filipenevola
1 Like
Honestly I feel like that is just semantics and doesn’t address the issue that this change will break existing packages that apps rely on. After thinking on this quite a bit though I don’t think even my suggestion is going to be a solution since the constraint resolver will find any packages that haven’t been released with a versionsFrom that explicitly tells the build tool that these packages are compatible with V3, to be incompatible and won’t allow upgrading anyway. This will render my suggestion moot. Unfortunately I think we are going to have to accept the chaos and carnage that the 3.0 release is going to create.