Abandoned Packages on Atmosphere and its effect on Community Morale

packages
1

I think it is important that people feel like that packages that made MeteorJS such an initial success will be continued to be maintained and enhanced into the future. Can we use this topic as an area to collect input as to what important packages are in need of a maintainer and then try and identify people willing to take on that task. I would personally like to see raix:push maintained and I made my availability know to raix on Github, but another package people frequently mention is iron:router. So I will add those two to the list to get it started. I have the time to help maintain one of these two packages. So if raix:push is covered then I will volunteer for iron:router. I have been a software engineer for about 6 years but i am not as experienced as a JS developer so any assistance would be welcomed :slight_smile:

raix:push
could use some help (it is not abandoned just in need of assistance)
iron:router
this package has been inactive for about 2.5 years so it could use a new maintainer, and hopefully the original publisher could provide a bit of a knowledge transfer to get the renewed effort started

5 Likes
2

Maybe we need more of a matrix of old vs new packages. There are many I use that have newer equivalents, but I’m not always aware of them. For Iron:Router - most have moved over to Flow Router, which itself has a better maintained alternative version. It’s hard to keep track of it all.

There is an attempt to gather some of the most used packages and get them in a pool where engaged developers can provide timely updates. Meteor Community Packages. Check it out.

4 Likes
3

ohh nice … this is definitely what i was thinking of. A place where the stuff that matters to people could get taken care of.

And i agree that iron:router may have been kind of surpassed, but some people like it best even to this day. So i’d like to see if people would like to be maintained into the future

1 Like
4

Hi there. I wanted to refurb. RAIX:Push more than a year ago. I found it was so full of old tech and docs (which could not be deleted because people were still using old versions of Meteor) and an update wasn’t really feasible. I could have just forked and did another version of it and re-merge etc… Ok, I did that. My fork was so far away from the original and after a very short chat with Raix, I decided to separate from RAIX:Push entirely. https://atmospherejs.com/activitree/push is up to date, supports pretty much everything that Cordova supports, needs some updates here and there which I will do once I am back to Cordova. I think this is a general pattern in development, people write or update a package once they work on a project and then leave it behind until they need it again. I learned to rely more on forking than on waiting. So, if you need a good Push package, the one I maintain resembles Raix logic, uses the up to date libraries from Firebase Admin (the actual latests Push tech from Android) and APN for IOS. It can be easily adjusted to use Firebase Admin for both Android and IOS. If you want to co-maintain this, I’d be really glad to have/share this experience with you.

6 Likes
5

That’s a pretty neat idea! Maybe we could add it to the Meteor Guide or to the community landing page.

3 Likes
6

This is one of those examples! I used to use raix:push for an app, but it stopped working at some point, and I never got it working again. I’ll be checking that out soon. Thanks!

2 Likes
7

Let me fork the repo you have on github and i can start looking over the code

1 Like
8

paulailincai (in Dubai, UAE) on skype if I can be of any help in clarifying anything about it

2 Likes
9

awesome thank you.i will reach out next weekend after i have a chance to look through it and get up to speed a bit.

1 Like
10

How do you see the structure of this matrix? Is it old package vs. new package? What do we do when there’s more than one “new” package? There have been forks on Atmosphere projects when the forker wanted to go in a different direction than the maintainer. Should those be taken into account too? How do we evaluate what’s canonical, and what’s the legitimate “heir?” I’m not trying to be argumentative. I’m just trying to get a sense of how this table will look so I can be useful helping out.

Personally, I think we should prioritize those packages that the community feels has the greatest value and look for recent forks or recent substitutes. The “Trending” list is a useful guidepost.

@storyteller I think the suggestion is good and a simple markdown table on the community landing page, or a subpage would be sufficient, IMHO.

1 Like
11

I can think of two main ways - one is just to follow which fork of a dead package is still active, and evaluate from there. The other is to address a problem domain, such as push notifications, or fast-render/SSR, etc.

In either case, the real question is who does the work to catalog all this, and get it in to some sort of understandable data structure.

1 Like
12

Atmosphere should be deprecated in favour of an NPM method of including client/server/mobile packages. My hopes is it would eventually be removed entirely from Meteor which could reduce complexity of the codebase.

FUD but: MDG has no resources to do such a large change let alone support it while focusing on Apollo, and it would probably go against business strategy for lockin.

13

I like https://atmospherejs.com/patrickleet/tags.

I couldn’t get it to work out of the box so I forked the repo and installed locally, made the changes to work and then issued a PR.

2 Likes
14

my understanding was that npm would eventually “replace” atmosphere moving forward and this step would simplify the management of dependencies and make it easier for people to keep track of the packages that would still being maintained. I may be wrong about this and if anyone knows anything about a timeline for this or anything really please add it to this thread :slight_smile:

My hope for this topic was to try and compile a list of the packages that people felt were the most important to continue to maintain (maybe like 20 - 40 to start to make it manageable). And then with that limited scope try to determine which of these projects is “covered” and where could a new person make a meaningful contribution by helping out. I am all for using the Github project mentioned above GitHub - Meteor-Community-Packages/organization: Discussions on organization of the organization 🎩

1 Like
15

I don’t think NPM packages can’t replace all Atmosphere packages as things stand. Atmosphere packages are designed to support isomorphic, full stack code (client, server, assets) which is not doable (as far as I know) using NPM.

That is why you can find some Atmosphere packages that capture full functionality vertical (UI, server, and DB) which you can’t do using npm packages. Simply put Atmosphere packages are more powerful than NPM packages.

4 Likes
16

Svelte packages are shipped uncompiled on npm, with a custom entry point defined in their package.json files. Meteor could do something similar - add a meteor entry point to allow multiple files to be linked in the package, and configure eager loading, etc…

I’m not sure about non-code assets (can they just be listed in package.json’s “files” array?), but I think you can deploy stuff like node binaries, and webassembly modules to npm, so I don’t see why you couldn’t also deploy images and css files.

I think part of the idea behind not moving to npm was that the folks at MDG wanted to not just move existing patterns to npm in a hacky way, but work with the community to create some kind of idiomatic solutions for each problem. I think at this point that idea has aged out - maybe it’s time to rethink that?

At the same time, what problems does moving to npm really solve? Some of it’s versions constraints are peer dependency systems might be a bit better, but moving everything over is a lot of work - is it really worth it? I don’t find discoverability any better on npm compared with atmosphere.

2 Likes
17

I’d like to go through the exercise of building a isopack just to see what goes into one. thanks for the information though

18

A case to point, take a look at one of the VulcanJS packages. You’ll see see client, routes, server, tests, stylesheets, assets all in one package. Another great example is the redis-oplog package, the package override default system behaviour on both the client and server then deliver it in a cohesive backward compatible bundle with a one liner installer published on an online registry, now that’s awesome.

I don’t think this is currently possible with an NPM package, point me to an open source NPM package that has this structure and I’ll stand corrected.

2 Likes
19

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
20

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