I understand that about the solution from @efrancis. And this is also why probably there it seems to be a need for some core development before NPM packages could really replace Atmosphere packages.
1 Like
I guess it would not be too far off here to say that for that kind of proper progression, the long awaited complete move to npm (meteor core packages on npm) is necessary.
But I should admit that the more I use npm, the more I feel like atmopshere is a more developer-friendly package system 
3 Likes
Yea, I like atmosphere packages as well. Especially when you consider their support for multiple architectures.
4 Likes
I don’t believe that’s necessary, part of Meteor trying to make client and server act the same is that on the client global === window, they’re aliases for each other. But if Meteor packages are ever available outside of a Meteor context that may no longer be true, so I’ve just published 0.1.1 that uses window on the client instead.
Yea, I like atmosphere packages as well.
Me too :\ it has some features that npm just can’t provide an alternative to yet. I’m hoping this proposal or something similar gains traction this year, but it doesn’t seem very prioritized.
2 Likes
Well, perhaps we’re not to wait too long at least from a meteor-support perspective: Preserve true "main" and "browser" fields of package.json modules. by benjamn · Pull Request #8213 · meteor/meteor · GitHub
1 Like
Yeah without internal changes to npm we’re stuck with a runtime solution instead of at dependency load time. Here are a couple ideas, neither of which I’m in love with:
- I suppose someone could make a wrapper around npm that helps with resolving Atmosphere packages, akin to how yarn wraps npm
- when the
meteor-packagenpm package above sees a missing dependency missing and logs the error asking the user to run "meteor add <name>"it could theoretically spawn a child process and run the “meteor add” command for you, which would automate the process more, but that is admittedly really hacky and doesn’t solve different version requirements (luckily Meteor has done epic work to keep things backwards-compatible). I believe the meteor dev server process would need to be entirely killed and restarted as well
1 Like
Shoot, wish I had found this before I published my Galaxy maintenance package to Atmosphere. 
I tried npm first, and kept getting errors with regards to importing meteor/mongo.
1 Like
Here is my biased opinion. Frankly before meteor mentioned moving to npm I never even considered writing or even rewriting my logic for the node ecosystem. I as well as other community developers went through endless nights of no rest and sickening worries , wondering if I was falling behind because I continued to write packages in atmosphere and not on npm.
Until I realized something very important. The whole push to write packages for npm vs atmosphere came shortly after the React nightmare 
(not truly , but the scare ) and meteors position on react being superior to blaze.
I spent weeks learning react , angular and kept finding myself missing blaze. I learned a lot of great things from react which inevitably lead me to appreciate blaze-components.
Then I asked myself the big question what’s wrong with Atmosphere ? I mean really. I’ve written several packages and not once has Atmosphere or Meteors packaging system failed me or held me back.
Then I realized I was worrying myself because of the hype.
My closing thoughts. atmosphere is amazing. Blaze is amazing and will be better. If the whole point of writing packages for npm is just for the sake of embracing and welcoming a larger group of the js community then perhaps I’d prefer to buy each of them a coffee open my laptop and introduce them to meteor create the-best-thing-ever
Just my opinion.
7 Likes
It’s a complete shame but the core developer left on Meteor thinks package.js is a “laundry list”. This is how out of touch MDN got from the original Meteor spirit - they just don’t get it.
Meteor has amazing roots, and it is the best web framework, but their developer(s) are completely prone to hypes. They didn’t skip any of them: Angular (which finally died), es6, react…
I just wish they won’t keep destroying it - as they did with any version since v1.2 .
Wish they were sticking to the roots and kept their apis backward compatible, so the amazing hard work, done by so many devs, wouldn’t go to waste.
They give us a feeling in the docs like they are going to take the ground off our feets and close Atmosphere tomorrow, where in fact they got nothing to replace it - what a shame. So glad Mitar started this thread, to show how poor the situation is.
Stay vigilant people and love Blaze - we survived Angular!
-Daniel
2 Likes
I couldn’t agree more. I understand what happens with hype frameworks. They should definitely be evaluated. However when you are engineering a project and the decisions you make within the architecture aspect of the project may potentially affect thousands possibly millions some day you have considered backwards compatibility and the community you re working with.
Again this is not to bash MDG because without Meteor this thread wouldn’t exist. But I do feel as if giving the community the impression that Atmosphere will be shut down or it has some negative impact vs. Npm was not a smart move. Look at yarn for example and many other npm alternatives.
3 Likes
I absolutely agree with you guys. I don’t get why some people try to move their meteor opinionated packages to npm. Doesn’t make sense at all if you ask me. And if you do, you have to go through build script shit and npm link nightmares…
Actually it’s npm that is just crap and we try to use it because it’s supposed to be standard (at least for the next 100 days)
1 Like
I second on that. Still, I haven’t seen any solid approach to replace Atmosphere packages completely. I do understand that npm is widely used, and in fact, when I first encountered Meteor, I was wondering why they invented their own package manager instead of using npm. But now I know. And I cannot understand that MDG is pushing things towards npm without having established a full alternative on that basis, i.e. including support for different architectures, especially mobile, which still is a strong USP for Meteor’s build system.
1 Like
After encouragement from some people here I brought back the post I removed.
It is rude, and that’s why I removed it - but it came from the heart, MDG you’ll have to forgive me if it is too offensive, but it reflects real feelings in the community - be more in touch with us.
I want to give few examples for how bad the situation is:
-
https://github.com/meteor/meteor/issues/7842
This bug broke my project when it came out, it also broke this amazing package: https://github.com/Nemo64/meteor-bootstrap.
The developer of this package didn’t even investigate why, he just abandonded it. -
When upgrading to v1.4.2.3 I found that Arunoda great https://github.com/meteorhacks/inject-data broke, not sure why.
As you know, Arunoda left us already, and this package isn’t supported any longer.
I managed to find a fork here: https://atmospherejs.com/staringatlights/inject-data that fixed the issue and saved the day (pure luck, if I did the upgrade immediately when it came out it would take me hours to work it out). -
My tap:i18n package, loved by many and endorsed by the Meteor docs themselves, got broken with API changes to the point where it doesn’t work for many edge cases.
-
Take a look here about the hard time of getting sass (!) to work on v1.4: https://gist.github.com/theosp/1906aaa1e0b46aa6ceaf5c6cd4f17ab7
Every release of Meteor is net-negative for me, a bunch of hyped features that I don’t even use or need, and a set of breaking changes that destroy my build and 3rd-party packages I am relying on. (I must upgrade for security reasons).
It totally surprised me, and it still does, how for a project that is so dependent on community work the time from release candidate to release is a matter of few days! nothing can work this way, zero time for the community to test and respond - no process with the community.
If Meteor wants this fast release cycles it can work only if it will take a list of all the top 500 community packages and make sure they aren’t breaking by their release - and still I wouldn’t recommend it.
Without this every release destory the confident of the developers - and that is why we see the calls for community fork.
And, just another note, ever since the close of the mailing list, I lost touch with the community, I simply have no time to read 100s of messages in the forums (regarding the Community Fork effort, how things are going with it?) the mailing list keep me in touch, since at least I can read few lines from now and then of the things that are going on…
-Daniel
3 Likes
Thanks @theosp for your post, I couldn’t agree more. I’m still on 1.2 with my app, since every attempt to upgrade it resulted in hours (!) of unproductive and very frustrating research. This was the case when I migrated from 1.1 to 1.2, and it was also the case when I tried to upgrade further. All of these incompatibilities were eventually related to breaking changes in the build system, and many of them affected SASS. Let’s make this crystal clear: I still really love this great platform, but the upgrade nightmares do scare me.
(The issues you linked were a very interesting read. I was just about to implement inject-data for SEO, but now I will think twice. Would be just another puzzle piece doomed to break.)
@seba, check the above thread, you wrote:
“Although a bit outdated with the move to NPM. As the developer of https://github.com/sebakerckhof/stratosphere (private meteor package server) I could write a section on how the meteor package system works.”
There is no signs for transition to NPM in the coming future, and your work is invaluable. One day might even be part of the stack that will help us to fork away from the main branch when it’ll get completely astray.
-Daniel
1 Like
Stratosphere was really cool I tried it I believe 2 years ago and really liked where it was. I am the author of Scorpius the fork if Orion , and it would be really cool to see true systems come together to push a better community.
@theosp let me know if you plan to work on Stratosphere I’d like to help get that up to the visual appearance of atmosphere
Never heard of Stratosphere yet, that’s pretty cool! At the moment, I am using the PACKAGE_DIRS option to get access to private packages, but this server solution is way more elegant. Is Stratosphere being actively maintained? I am asking since so many packages become deprecated these days, and using such a private package server would quickly become a vital part of your development setup.
I haven’t used stratosphere in about 2 years, but when I used it it needed a little work and the author was reaching out for assistance. At the time I didn’t have enough bandwidth to contribute, but I can see something like Stratosphere going mainstream.
I can even see stratosphere leveraged to a paid service or SAAS.
My first take on making NPM and Atmosphere package at the same time: https://www.npmjs.com/package/fiber-utils
3 Likes