Is it only my feeling, or 1.4 is not really compatible with previous version of Meteor.
I’m trying to install a few packages into fresh installation of Meteor (1.4.1.2) and getting problems, many packages seems doesn’t support 1.4 or works incorrectly.
I can’t use postcss (juliancwirko:postcss become very slow after upgrading into 1.4).
I can’t even use semantic:ui (While checking for semantic:ui-css@2.2.4: error: No compatible binary build found for this package.)
It hard to find still working admin package (orionjs:core throw errors, yogiben uses iron:router so I event don’t try it, sach:flow-db-admin shows error: no plugin found for lib/client/css/admin-custom.less in sach:flow-db-admin; a plugin for *.less …)
Many packages have assumptions about collections in global scope which is not true anymore after introducing import syntax.
MDG, you should really should find some solution how to find which package from atmosphere is still compatible with newest version of your framework!
I think you may be just unlucky with your package selections, I have dozens of packages in my projects and I didn’t have any problems after upgrading to 1.4. Still, I feel for you, it sucks when those things happen.
Didn’t MDG say that they’re going away from the “atmosphere package” and started going with npm packages instead? Not sure if it’s the cause, though. I think you should start familiarizing yourselves with using node modules instead of meteor packages, soon, you won’t be able to use those (just a hunch).
They’ve said they will be focusing on having first-class NPM support because that’s what the rest of Javascript community is doing, but I don’t recall them saying anything about Atmosphere going away any time soon.
In Meteor 1.4, they changed the build pipeline so it build plugins that require a binary aren’t compiled on the Meteor build farm anymore. Now, they’re built locally on the package maintainer’s machine. It’s impacted the CSS build pipeline particularly bad, especially for those people using SASS and .scss.
I feel like this is a similar topic to the whole ui layer chaos, where meteor developers had not really a choice pre-1.2. we used blaze and we used atmosphere packages because we were told to do so and support for alternative technologies (community based react integration, meteorhacks:npm et al.) has been declared a “hack” or workaround. less and coffeescript same thing.
Now we have the big freedom and meteor opens up to apollo in the future as well. Which gives us a huge amount of possibilities writing modern web apps on top op meteor.
But at the same time, it lead to major atmosphere packages beeing dropped by their writers. Autoform, collectionfs, useraccounts, flowrouter and orionjs? community leaders lost trust in the sustainability of their packages and people tell us that you should not use “opinionated” code. fair enough.
It’s not about the framework beeing incompatible, it’s about the package owners losing trust in the technologies they initially used.
I fully understand moving forward to newer technologies. It’s common in software development. But I would hope that they at least come up with a migration pattern for these packages as compatibility starts to break over the next few major updates.
At the very least a way for us to bring them over to NPM and have them work with our Meteor projects. That way, even if the package owners are MIA, we could just port it over to NPM and be set.
It just really sucks that some of these packages are straight up NEEDED for Meteor-specific behaviors that are integral for almost every website out there. Many include features that (imo) should have been integrated in to Meteor directly (such as roles, pagination, some form of routing, some of the useraccounts features).
Sure, NPM has packages for some of the same features - but you can’t use any random NPM pagination package and expect it to work in Meteor properly. Those packages won’t control pub/sub/etc, so it simply wouldn’t work. NPM roles packages wouldn’t account for Meteor’s security. etc.