I would like to emphasize in repostatus.org which introduces machine readable badges to indicate repo status. If we can make enough package maintainers to includes the badges we can show on atmosphere the active ones as “active”.
4 Likes
I don’t see any reason Meteor couldn’t add a meteor key to package.json which contains all the necessary config to make the package work from npm. Svelte is doing exactly this already. Here’s that Vulcan example translated:
{
"dependencies": {
"@vulcan/core": "^1.13.2"
},
"files": [
"lib/stylesheets/style.scss",
"lib/server/main.js",
"lib/client/main.js"
],
"meteor": {
"versionsFrom": "1.6.1",
"mainModule": {
"server": "lib/server/main.js",
"client": "lib/client/main.js"
},
"useAtmosphere": [
"fourseven:scss@4.10.0",
"dynamic-import@0.1.1",
],
"addFiles": {
"client": [
"lib/stylesheets/style.scss"
]
}
}
}
This is obviously just one way to translate the data. I can’t think of any Meteor package API that couldn’t be translated into static JSON. We could even bridge a transition period by having a “useAtmosphere” key in there for old packages that haven’t made the jump yet.
5 Likes
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