We're planning three similar vue projects. We already know that we will be able to reuse a lot of code (especially vue SFCs and simple js helper functions) in all of them and we're looking for a proper way to share the code between them.
Unfortunately the scope of the projects is rather different and a monorepo is not an option due to its limitations in read / write permission and visibility management. Therefore we're planning to handle the reusable parts as separate repos (and most likely private npm packages) which seems to be a straightforward approach. However, the question is: How can we create a convenient setup in which we are able to work on the shared components from within the scope of one of the parent projects?
Project A [project-repo-a]
- project-specific stuff for A
- private package A [package-repo-a] (conveniently editable from within project A)
- private package B [package-repo-b] (conveniently editable from within project A)
Project B [project-repo-b]
- project-specific stuff for B
- private package B [package-repo-b] (conveniently editable from within project B)
- private package C [package-repo-c] (conveniently editable from within project B)
In our PHP projects, there is a simple solution, we just require the reusable parts via composer with the prefer-source option which provides the full git repository which can be worked on right from within the parent application. However, as far as we understand there is no prefer-source thing in npm or yarn. So how can we achieve the desired setup? (Or are we overlooking a major downside of this setup in general?)
We already looked into / considered the following (without finding a suitable approach):
- yarn / npm link: We understood, that we could use linking in general, but this seems to be a very inconvenient approach while constantly developing the shared components (and always having to publish them to reflect the latest changes).
- yarn workspaces / lerna: Seem to be closest to what we want, however they seem to be (or are explicitly) designed for a monorepo approach. In the end they don't to provide a solution for actually getting the git source of a package (in a separate repo) into the parent project (since there is no --prefer-source thing) - do they?
- using composer additionally: Just pulling the git sources down with composer and creating yarn workspaces from the composer vendor folder. However, this is obviously a hacky way and sounds quite error prone concerning the whole dependency management
- using a yarn post-install script to pull down the git source of the required private packages, but as the composer way, this seems to be rather unpredictable in terms of module resolution, dependency management and so on.
- using git submodules and yarn workspaces: Could be a solution. To be honest we're just completely unexperienced with git submodules and at a first glance it didn't look very intuitive. If there is no other way, we'll anyways consider to use this approach.
To be clear about this: We're not asking the taste question if one or the other of those approaches would be "best". We're feeling like none of them is the right one. The question is: Are we overlooking a technically clean and proven approach to our scenario, using npm, yarn or another package manager / dependency management solution?