Thanks @filipenevola. This is the first time I have seen the PR.
Seems like this is the case. However, it might still be possible to create the standalone package you suggested if it is not part of the core.
If this is in fact the case I think that would be fantastic. From as far as I understand about how the the constraint resolver works though, I don’t think this is going to work. I’d love to be proven wrong though.
Sorry, I was not able to completely read your previous message until the issue with the version.
Maybe meteor-compat can once again be used for the transition
What would be example of major breaking changes that comes to your mind? Trying to understand the impact more. Eitherway, I think it’s worth it, 3.0 is a breaking change and major upgrade that is necessary for the longevity of the framework, might as well take the hit with the removal of fiber.
@alawi basically any app/package that uses WebApp.connectHandlers and the like, will cease to work. The realization on my part is that trying to monkey patch as a temporary fix will be rendered useless by the inability to be included in a project that doesn’t resolve their versions as compatible with Meteor 3.
I’m definitely not arguing that the upgrade isn’t necessary or worth it for us, and others who currently use and rely on Meteor to meet their needs. I’m just lamenting the fact that it will create further fragmentation and abandonment in an already battered and broken ecosystem. This will ultimately lead to migration to other frameworks/platforms where these issues don’t exist as well as create resistance to adoption, neither of which is good for the future of Meteor.
Understood, but many frameworks went through something like that, vue, angular etc. Meteor has been mostly backward compatible, it’s just after a decade, especially in the JS ecosystem, something like that is bond to happen. Npm and react is full of abondended packages, it’s just the nature of open source, I had to rewrite my react apps 3 times 
It might be a good opportunity to revive/modernize important packages. Maybe we could add filter and tag in atmosphere to differentiate between v2 and v3. Also a lot of folks in Meteor, adopted npm packages etc, so I don’t think it is that impactful. New Meteor apps won’t have an issue and legacy will need to migrate, key atmosphere packages will be revived and things will move on to the better, it’s just the transition and the story around it has to be well managed.
Meteor done better than most of projects that came from that period, at least it has a path to be solid in the future. I think focusing on backend and deployment and decoupling further from the front-end is the way forward.
2 Likes
Last reply so as not to detract from the original intent of this thread
Yeah, I understand. Meteor however isn’t the same as React or Vue, or Angular. Those are libraries and are small and encapsulated by comparison. They don’t have 100 interdependent pieces. That fact and the fact that these changes aren’t to innovate, but to play catch up with the rest of the ecosystem, makes this case categorically different.
Yes, but this is different. These are Meteor packages, most of which are designed to work with Meteor. The abandonment of NPM packages is less of an issue because they exist as part of the larger ecosystem, and for the most part are replaceable.
You are absolutely right… The various teams that have worked on meteor over the last nearly 12 years have done a great job. The fact of the matter though is that I don’t think it wasn’t enough. There wasn’t enough funding or enough man hours to accelerate it into the future and I really hate to say this, but the dinosaur killer became the dinosaur.
More confusion isn’t going to attract new developers and even devs that have been here since the beginning are going to have a harder and harder time starting new projects with Meteor when they can get a superior DX using a few packages on top of Next.js.
I love Meteor. I wouldn’t be a developer today if it hadn’t come into existence, but I’m ever more worried about it’s future as time goes on.
2 Likes
You make a valid points/concerns but I’m a bit more optimistic after 3.0. I think meteor will have a good niche and market akin that if ruby on rails and if it focuses more on backend/hosting it might do really well.
But anyway, migrating away from fiber, updating node and swapping express to just stay up to date it seem.to be a must, so they are beyond debate as far as I can tell. I would be more worried if those are not done.
1 Like
@filipenevola, am I right in my understanding that any packages that have used connectHandlers before will still work without changes (considering no version constraints)? Anything that uses rawConnectHandlers must be updated, similar to how we treat rawCollection when MongoDB is updated.
We could agree to consider this version of webapp “compatible” and skip the major version bump. (the core team would need to double check all the changes)
Of course, this solution is not applicable everywhere, but maybe valid here? TBH, I’m unaware of how many packages depend on webapp.
Both handlers (raw and default) are the same. They expose connect (and now express) handlers.
The raw refers to be applied first in the chain.
The good news is that connect and express are compatible in many ways, especially at the handler’s level.
I would not expect everything to break. You should be fine if you use use and other things in a standard way.
I’m unaware of any real case in the Meteor community where the replacement from connect to express broke anything. Even if we find those, we could create a compatibility layer inside webapp. Report here if you know any.
But I understand the concern in this thread, probably because of other breaking changes that are coming, especially for MongoDB.
2 Likes
Hi all, my PR is finally done. It was missing the updates in the comments and checking other compatibility things like error handling.
Please review:
3 Likes