I see, so basically inject the Meteor package.js entries info in the NPM package.json and have the Meteor build system process those entries from package.json which will allow publishing meteor specific packages to NPM.
2 Likes
Another thing is that Atmosphere packages let you easily differentiate between target platforms, which comes in especially handy when developing mobile apps.
But I think @captainnās approach might work for this. The only concern I would have with this is that these kind of packages would behave differently if you use them with or without Meteor. Iām not sure if this is in line with the philosophy of npm and the rest of the eco-system.
The other thing is that I donāt see much value in that move to justify the effort. Those meteor npm packages will still be used only within meteor and npm is not really much of a superior hosting platform than atmosphere.
@captainn mentioned this as well.
There are already a bunch of different platforms on npm. Many node packages donāt work in the browser, and many browser packages donāt work in node - then thereās all the typescript and svelte packages. I wouldnāt worry about that.
I think the biggest problems are:
a) the fact that many Atmosphere packages are abandoned, and nobody cares about removing them (or at least flagging them as such); this causes a lot of frustration, especially to beginners who are not that familiar with the ecosystem
b) the user interface of Atmosphere; I personally find it particularly annoying that it is not always easy to get from Atmosphere to the corresponding git repo
c) MDG stopped embracing local Atmosphere packages, which actually had a lot of benefits IMHO, especially when it gets to modularisation
2 Likes
Iām sure youād agree with me that an abandoned package doesnāt mean itās not useful, Iām using many abandoned packages, I evaluate the risk case by case. I think this is an inherent feature of open source in general, many developers like to create and share but few like to maintain, understandably so since maintaining an existing code is not as fun and socially rewarding as creating it thus few would be willing to do it long-term without economical incentives. Meteor is almost an 8 years old framework, which is an achievement in the JS land, thus many people will come and go leaving their libraries behind.
I donāt see why Atmosphere should flag those packages, itāll discourage the use and forking which is against the spirit of open source, I think folks should just go to github and use their judgement. To be able to rationally evaluate the risks of using a package is a skill I think every open source user should develop.
Iām not sure about that one, last talk from Benjamin he praised Meteor packages.
2 Likes
I think it would already make sense to display on atmosphere, which Meteor versions are supported (api.versionsFrom) and how much do they differ from the latest release in major steps.
3 Likes
The problem is to find out if this is the case. There are a lot of packages from Arunoda, for instance, that included some āhacksā that simply donāt work anymore, like the meteor streams package. Sometimes, there are alternatives available, but finding them is not easy. It would be easier, though, if the original packages would have been marked as obsolete, including links to successor packages.
Since this relies on some maintenance by the original author, one could also think of adding comments to packages on Atmosphere, so the community could provide feed-back.
The state of the Atmosphere ecosystem made me follow an advice skinnygeek gave a long time ago: avoid community packages as much as possible. I did no get it when he mentioned it, but now I know. I only use rock-solid community packages like simpl-schema.
Glad to hear, but who knows about these talks? Not everybody lives in SF. At least the Meteor Guide suggests using ES6 imports and an app structure where nearly everything lives inside an imports folder. I am structuring my apps this way now, too, also because it makes integration with editors much easier. But still, I liked local packages very much. The modularity of my old Meteor apps was way better. I even shared packages between them without copying them around, thanks to the package dirs folder.
I donāt think there is anything discouraging you from doing this - the imports directory handles one set of common use cases (strict imports, distinct code bases) the local packages system handles another set of cases (e.g., local modifications to public packages, custom shared packages, etc)
We use both quite happily, weāve got āfixesā to 3rd party packages, a ācommonā package we share between our apps, and a custom package that isnāt ready for public consumption yet in the packages dir.
Our imports dir has all the code that is specific to each project. These play perfectly nicely together
3 Likes
The import syntax is a JS syntax, so Meteor had to support it otherwise it would have been completely cut of from the rest of the ecosystem.
For the packages that donāt work, again that is an issue with open source in general, same thing can be said about some react packages on NPM,
That could be an improvement (like a flagged package), NPM doesnāt have that feature either but it would be a nice enhancement. But then again, that needs some design/thinking, how many people should flag that package? what if someone flag a package that is actually working? what if the author update the package can he/she unflag? etc.
A lot of Atmosphere packages were wrapper around an NPM package and they tend to lag behind once the NPM package was updated. Since Meteor started supporting NPM, I only use the main npm package and only use Atmosphere for Meteor specific packages.
I agree with Atmosphere needing to provide more of means of people adding feedback on a package.
I think the star system is a start, but a more detailed download graph and a comment area would help. then you could get a better sense of the pulse of the project by it last release date, the download frequency, the comments and i the number of stars too.
Those four things in combination would give a decent depiction of whether a package was still active and useful.
Thatās how we do things for PixStori too. I had created a custom data subsystem which would do SSR, data hydration, and loading data over methods instead of pubsub. Since that was something of a core package, it made sense to put that in packages. After that initial development settled down, and everything was working, I spent some time to formalize its API, and we released the package as npdev:collections (which really should have been called npdev:react-connectors` or something like that).
We have other patched collections (things like alanning:roles, and various aldeed packages) mostly to remove underscore and other bloat (PRs are always submitted, but not always merged quickly).
I even have a custom react-meteor-data with the latest hooks work locally (which actually pulls the hook from npdev:collections since Iāve shipped that hook in my package), so that I donāt have to wait for MDG to merge those changes.
Itās a great way to work. Honestly, itās much easier to fork and work on Atmosphere packages compared with doing the same for npm packages.
1 Like
Most of these types of tools exist in GitHub. When Iām evaluating a package either on Atmosphere or NPM, I generally check the GitHub repo to look for things like the most recent commit date, and how many contributors there are, etc. You can tell a lot about the likely pain a package will cause by looking at the commit and release history in GitHub.
1 Like
True. But since Atmosphere does not enforce linking packages to git repos, it often takes ages to find out where the corresponding repo actually is.
I follow similar decision process as @captainn if I donāt see the GitHub code I donāt use the package.
3 Likes
Some updates on this topic. There are two related open pull requests, that might be interesing here:
1 Like
Since my business started using Meteor in 2015, all the Meteor projects weāve been involved in have relied on iron:router.
It works well and there are only a couple of small issues that concern us at the moment:
-
If you call Router.go() while scrolled down the current page, your next page will rendered still scrolled at the same point (see this post).
On my development todo list, I planned to create an updated fork on Atmosphere named āsteel:routerā or āgalvanized:routerā, but Iāve had bigger fish to fry, so happy for you to take the initiative.
2 Likes