Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardise a mechanism for cross-package dependencies #941

Open
philbooth opened this issue Apr 26, 2019 · 2 comments

Comments

Projects
None yet
4 participants
@philbooth
Copy link
Member

commented Apr 26, 2019

I thought we already had an issue for this, but couldn't find one. Close as a dup if I missed it.

Currently there are two mechanisms in play for cross-repo dependencies:

  • The historical approach of adding them as dependencies at the npm level, in package.json.

  • The ad hoc approach we rushed through for the auth db, where a dependency is copied into consuming packages by scripting.

The disadvantage of using npm is that it enforces a multi-step approach, where changes must be published before they can be used in-tree. It's also node-specific.

The disadvantage of the ad hoc approach is that it requires scripting to run for the dependency to be present. I think I caught most of the cases in that PR but still, it's kind of messy and wastes disk space (which would be more of a concern if we were to adopt it as a standard mechanism for all the deps).

In an ideal world, if we get #694 done we might find that the repo size including dependencies is small enough that we could use a single Docker image for all packages that includes the entire repo. Then we could just ../ up the tree willy-nilly. That seems like it would be the simplest approach, but is weighed down by the fact that #694 is not a priority and will likely hang around for a few months yet.

Maybe we could introduce a generalised version of the copy approach in our scripting as an interim measure, e.g. where we look for certain dependencies in package.json then do the copying for all of those in the same places that we did it for the auth db stuff. That would mean adding a package.json to the email service, which is written in Rust, but I don't have a problem with that.

Plus there's probably other possibilities I haven't considered here, @mozilla/fxa-devs feel free to weigh in with suggestions or whatever.

@philbooth

This comment has been minimized.

Copy link
Member Author

commented Apr 26, 2019

/cc @clouserw, I think this is the biggest outstanding problem with the monorepo fwiw, in that it's the only thing I'm aware of that slows us down. But not by much and it's not a huge pain point.

@lmorchard

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

Can lerna help us out more here? I haven't played with it a bunch yet. I see lots of mentions in the docs about linking inter-dependent packages from the project itself, but scratching my head at whether it helps keep external dependencies in sync between local packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.