We need better support for working on packages

1

One of my goals with Telescope is extracting features into generic Atmosphere packages that can be shared with the rest of the community. But the current package workflow makes that pretty hard.

Problem 1: Dependencies on Local Packages

For example, I built Telescope using a modular package architecture to make it easier to add and remove features as needed. But I can’t publish any of these packages to Atmosphere, because they all depend on other packages which arent published to Atmosphere.

So either I publish every package to Atmosphere (including a lot that are only relevant to Telescope itself), or I can’t publish any.

I thought I could avoid this by using imply instead of use, but that doesn’t help.

Problem 2: PACKAGE_DIRS Issues

Let’s say I do manage to somehow work around the first issue, and I publish my Telescope packages to Atmosphere.

Now the issue is actually working on them. I know about PACKAGE_DIRS, but it’s not a perfect solution yet. First of all, it’s pretty opaque: how do you know when a package is being loaded locally, or remotely? How do you switch between both?

It also has its own issues. For example, I was working with a local copy of a package at version 0.7.7 while the published one is at 0.7.5, and I’m now unable to deploy using Mup because of a Potentially incompatible change required to top-level dependency error.

All of this makes it very hard to embrace the package ecosystem, especially if I have to find a way to explain all that to new Telescope users.

So I’m not sure what the solution is, but I think it’s worth having the conversation.

5 Likes
2

Did you find a way to deal with this?
I’m experiencing a similar problem: Top-level dependency error - don’t know why?

3

Not really, I just stopped changing the version of my local package copies.

2 Likes
4

I would like to see a way to work with and test with multiple versions of packages or at least multiple packages that implement the same thing.

For example, I have a package that depends on https://atmospherejs.com/momentjs/moment but would like to be able to also provide support for those who use https://atmospherejs.com/mrt/moment

I know it should be assumed everyone should be on the official package, but that is not the case. However, for now I have put a note in the readme of my package for those who might be using the un-official package.

5

@lbee I think the bigger problem would be other package authors including moment (or some other dependency) from unofficial packages. Furthermore, they pin down the versions at a very old version and they never update their dependencies so you are stuck with a very old moment or whatever.

6

just run meteor list and you’ll see locally loaded packages marked with a + (plus a comment about this at the bottom line…)

How do you switch between both?

I never played that much with PACKAGE_DIRS but I’m now wondering whether a sintax like PACKAGE_DIRS=folderA,folderB,folderC is supported: in this case switching from a local to remote packages could be doable on a package basis instead of on package lots…

Perhaps not that a huge of a contribution but still a partial answer :wink:

7

@serkandurusoy yep, that is an issue (I have found that in some packages I have used), I guess the developer needs to be aware of that issue when building an app, conversely package developers need to remember to update. Maybe some info on the Atmosphere page for a package could help (ie. dependency versions listed).

8

I’m working on a solution to this exact problem, rocket:module. I didn’t want to develop my next app without such ability to include libraries from other places easily (namely from npm (but more places if we swap npm with something like jspm), for the client-side, but this will work for the server-side too). The main concept of rocket:module is that packages depending on rocket:module will be able to specify npm dependencies and entry points, then rocket:module will use code splitting to compile (currently using Webpack) entry points into bundles via a plugin that I Package.registerBuildPlugined, with shared libraries code-splitted into a separate single bundle that will be loaded before the rest of the bundles of all packages in a given Meteor app. Absolute npm package versions won’t be a requirement like it currently is with Npm.depends.

Any thoughts or ideas?

9

Thanks for mentioning PACKAGE_DIRS! I didn’t know about this. I might have to account for this now. EDIT May 26th: Nevermind, I don’t think I do.

10

For those working with PACKAGE_DIRS, is there a way to depend on local packages when they are the most recent version, but still have other apps download packages when they refer to older versions?

For example, let’s say I am developing 0.6.0 of a package. I have an app that depends on 0.5.4 of this package, and I don’t want it to build the local version unless I explicitly refer to 0.6.0, instead downloading 0.5.4 from the server. Has anyone found a way to achieve this with PACKAGE_DIRS?