0

In work we have a pretty complicated stack and situation, which could be somehow described as the following schema:

enter image description here

The situation is:

We have an old, poorly maintained PHP/AngularJs project which uses webpack for bundling. We also have another project ("Some React Project") which contains a few sub-projects, and all of them are bundled into some bundle, which is then bundled with the old angularjs project. The AngularJs project then renders the React components from this bundle using some bridge library.

In addition, we have another modern React project, which is completely isolated and has it's own CI/CD process (it's actually another app).

Now we are going to develop a new module, using react, which should be used in all three projects. We first thought about maintaining it by publishing it to NPM and for each update, to deploy it in any project using npm install. The problem is that it has SO MUCH OVERHEAD. It is so very hard to test and deploy. It's hard to maintain and since some of our projects are very old, it's a complete nightmare.

Are there any other options available? Is it possible to somehow deploy to package artifacts somehwere, and then automatically update it in all the projects?

superuser123
  • 955
  • 2
  • 12
  • 24
  • what's the overhead you are referring to? using npm seems like a pretty decent solution. for quick testing using `npm link` is all you need – azium Nov 18 '20 at 19:11
  • also https://unpkg.com/ could be helpful here – azium Nov 18 '20 at 19:12
  • lastly, are you suggesting that updating your common library should autoupdate itself inside your applications? this is doable, not necessarily advisable. – azium Nov 18 '20 at 19:13
  • The overhead is caused by the fact that our CD and build processes are slow and will probably won't change anytime soon. That's a real pain to test things, even with npm link. – superuser123 Nov 18 '20 at 19:47
  • There's no library architecture / hosting solution that will speed up your CI.. – azium Nov 18 '20 at 19:49

1 Answers1

0

Have you considered installing directly from another repo ? Actually the overhead might be to have an auto-updated package. This would mean that you could never introduce a breaking change in that package.

{
   "dependencies": {
    ...,
    "common-package": "git+ssh://git@<your_forge_host>/path/to/<repo>.git#<your_tag_or_branch>",
    ...
  },
  ...
}
jbg
  • 116
  • 1