Yes, No? It depends.
Are you already using NPM? Do you have access to an internal NPM package server? Have you ever used GIT directly for NPM dependencies in house?
- Yes, then do not break the mould. Follow your current pattern.
- No. Then you need to consider how you are going to do this.
Technically NPM supports GIT repositories as packages. However GIT support often breaks, or is incomplete in comparison to an NPM package server.
NPM Package Servers are not trivial to install, configure, or maintain. How do you intend to support them?
If you do not want to rely on NPM, then your choices are:
- git checkout to a subdirectory.
- copy the package into a local directory and manually update it.
Neither solution is great. I would lean toward the second only because hierarchical git checkouts can become problematic.
However the manual solution requires diligence especially if there is an implied coupling here. Like every project needing the same look and feel, or the communications layer needs to be identical between projects.
Consider further breaking down the shared components so that only the actually required shared functionality is actually shared.
Like they would on the primary project repository.
- Make changes
- Make Pull Request
Of course you will need to have the diligence, tests, and automation to verify/update downstream dependencies (or notify of the need/issues).