Stratosphere - private package server

1

Hello,

I work in a team where we have various meteor packages which need to remain private for various reasons.
This is kind of annoying with Meteor, and it seems I’m not the only one experiencing this problem.

There exist some workarounds like mgp , but we have quite a lot of fast-changing packages and quite a lot of different versions are actively being used. Therefore I’d rather have something that blend in as close as possible with meteor. Ideally a package server that is completely interchangeable with the official one and where you can maintain private packages, custom versions of existing packages (e.g. custom DDP package) and so on. So I’ve spend some time looking into meteor tool and how the meteor package system works. It’s a lot more complex than with for example NPM or Bower. Especially since the code in meteor tool uses a lot of undocumented functions.

Anyway, I believe it can be achieved and I’ve open sourced what I have so far here: https://github.com/sebakerckhof/stratosphere

It can import packages from upstream and be used to sync packages with.
Quite a lot of code is already in place in order to be able to publish packages to it, but two main things are still missing:

  1. Meteor tool wants you to login to the meteor accounts server, this uses a combination of password an oauth login, so either I should implement an oauth server, or ignore user accounts, but I’d still need stuff that works for functions like getAccountsConfiguration (in auth.js of the meteor tool)
  2. File upload, but this shouldn’t be too hard.
  3. The github repo lists some other todos, but these are not necessary to get the system working

Pull requests will be more than welcomed. Especially for the login stuff.

5 Likes
2

Hi @seba! What is the current progress? At http://jssolutionsdev.com/ we were working on the same stuff.

3

Currently it’s fully functioning if you use meteor 1.2.
Haven’t looked into possible changes for 1.3.

1 Like
4

Seems that Atmosphere is moving to NPM - https://www.youtube.com/watch?v=7d0xTR-eYh0
It makes no sense to use Stratosphere.

5

Yeah, I said it in the other topic that I hope stratosphere can be replaced by NPM someday. However, NPM still misses some features to fully replace atmosphere at this moment. So I think Meteor 1.3 will mean the end of npm wrapper packages, but I guess it’d be at least another full year before we can do fully away with Atmosphere (and therefore also Stratosphere)

2 Likes
6

Fantastic work, @seba.

Going to try to find some time to set this up later this summer. Considering how short notice was given for the ending of the free hosting tier, it seems like a good plan to maybe begin working on a backup of the Atmosphere repository. Plus, who knows? Might be useful to have one’s own package server. Could be neat to add QA features to it and continuous integration hooks…

7

Thanks. Actually, because of left-pad somebody of my team is working towards removing any external dependency for our builds. Some of our software is sold like traditional software (you buy version X which you install on-premise, and the customer can buy X years of warranty and support). This means we should be able to still build that version from source within X years even if NPM and Atmosphere don’t exist anymore.

With Meteor this turned out to be quite tricky, so I’m planning to do a blog post on it soon.

1 Like