Hello Filipenevola, good to see you mixing in! Thank you for that.
Of course we know that you have no advantage whatsoever in breaking stuff up in every new release, or even, ever. But is that the point here? I think not. The point is, that Dependency Hell is a systemic weakness that never fails to deliver frustration and the need to put in countless hours to get something “fixed” again that was not broken before. And this weakness is baked into Meteor’s DNA as well as in many other platforms. And I am not even stating Meteor is doing worse here than competitors. It might very well be (as others here have stated) that Meteor is the brightest kid on the block here. But still. Dependency Hell is there, it is a real thing, and it can be frustrating as f. And I don’t even go out on a limb to suggest you know that from your own experience as well.
Now you ask: “Be very specific. It’s better to be specific instead of generalizing. Which change specifically did we make that caused problems for you?”. I can understand your question. You are trying to improve your platform, you want better. PDCA. You want to “fix” something, if it’s broken.
But again, is that the point here? I think not.
Since, whenever we update Meteor, there is gonna be “fear” and we have to wait and see whether the app still works or not. And by then, we do not know EITHER why it broke. Meteor simply produces a ton of gobbledygook and we are left trying to figure it all out, investing hours and hours in reading stuff and checking things. Is it Meteor’s fault? Probably not, at least, not in a direct way. You probably have done your work, you are following your processes, you have done your checks before releasing. But in most of our apps, we will have countless packages included that the app depends upon, and can Meteor also vouch for those? No, in the current way of doing things, you can not. And there lies my gripe, not with Meteor in specific (I think it is great!) but with the biosystem as a whole. Again, Dependecy Hell is a Real Thing. And therefor, it does not help much to be “very specific”. Sometimes, a discussion in a generalizing way, is the best option to see if one can come up with improvements in the overall design of things.
And that is what I tried to start here. I was aiming for a spark to ignite improvement. And although you will always have some that can not fail anything in their favorite product, the improvement comes from those that dare to look further and are not afraid to share experiences. Even if they are less enjoyable.
That is the inherent cost of using something for free.
When you need a functionality, you have a number of options:
Code it yourself
Pay someone else to code it for you
Look for available packages with the functionality you need
Each of these has pros and cons in terms of effort you do now VS effort you do later. Or potential effort when something might happen in the future: e.g. original developer is no longer available
As developers, that is part of the gamble we take everytime we decide on using that package or not. That package can save us time today but you need to understand that the same package can be the source of additional effort in the future.
That is also the reason why we need to be smart on choosing the packages we use. Is the maintainer active? Are there multiple maintainers available. Is there a community that can help when I encounter a problem? Can I or my team takeover when bad things happen? Are there alternatives as a backup?
Blindly adding a package because it saves you time now can be a huge technical debt in the future.
React has been on the top of my list for backwards compatibility, and in terms of explanation and documentation of things that changed and things that are about to change (most of the time months or even more than a year ahead).
Meteor is on the next tier of that list. It is not perfect, and there were decisions that can hurt backwards compatibility. But the good thing is that once Meteor gets enough feedback, they can and do reverse those decisions when necessary.
I feel you. I mostly had the same experiences when I was still using Meteor for developing mobile applications. Between 1.2 and 1.8 or so, upgrading was a true nightmare back then. Funny enough, the feedback from the community was mainly: everything is working fine for us. But most of them never used Cordova at all, I guess. Nowadays, I am using a native (Unity) app with a Meteor backend, which is just working fine. So I am on the other side of the fence now. (And I’ve heard that mobile is now a priority again, which is great.)
Regarding community packages: In the early days, I used them for every feature I could think of. It was like living in the land of milk and honey, the development speed was just awesome. But it came with a price-tag. At that time, I remember a guy named skinnygeek mentioning that he almost never uses community packages, and I did not understand his point at that time. But I learned it the hard way, when the Meteor ecosystem got some hiccups and many early community package maintainers moved on to other platforms. Tons of abandoned packages galore.
Nowadays, I choose wisely, and always have an eye on the latest updates of any package before I integrate them. Or I roll my own instead. This also drastically made Meteor life easier for me. And overall, after that first community fatigue, a lot of members picked up the work and tried to stabilize the ecosystem again (e.g. with the community packages initiative, which is great). I still choose wisely, but most of the community packages can be recommended.
Overall, Meteor is still the best and most productive full-stack ecosystem I know, and I don’t want to miss it. But you have to know how to play on that instrument to make the most out of it. And I am happy that it now has the support it deserves (by Tiny), while MDG seemed to have abandoned it.
Hi @waldgeist, respecting you I’ll post this link for the last time but I’m not going to talk about it anymore because it is too much noise for something that is very small. I don’t know why some people are trying to amplify something that is insignificant.
And as I said I’m not going to talk about it anymore as everything is very well explained in the issue linked above
It might not be clear from the issue why the error message started showing for some apps without any version or code changes. I was confused by that this morning and briefly looked into what was happening.
The Meteor CLI communicates with several meteor apps for things such as updating the local package catalog. One of those apps the cli communicates with recently started sending the { testMessageOnConnect: true } message. If you are using an old version of the Meteor CLI, it thinks the message is invalid and logs that it is discarding the message.
Besides seeing the extra message in the console, it doesn’t affect anything. Once that Meteor app is fixed to stop sending the message or you update to a version of Meteor that knows it is a valid message, you will no longer see it in the console.
Thanks for this explanation, @zodern. This helps alot to clear this issue. Without knowing that it was the CLI tool connecting to a 3rd party server, it would look like that something changed in our apps without us doing anything. And thus, that uneasy feeling of something out of our control that happened in our app.
