3

Is there a way for Hot Reloading to occur on a local npm dependency of a local Vuetify application using yarn serve (which is probably using webpack / vuetify-loader)?

BUSINESS CASE

We have some common Vuetify components that I'd like to expose with a "common-components" Vue Plugin and allow all of our Vuetify applications to pull those common components. I'm able to do so by packaging the plugin and creating the dependency and pushing to a private npm repo or a commit/push to a private git repo. The problem lies with the development cycle and development experience.

A typical development change to the Plugin within the local development environment requires:

  • (common-components) yarn build (to create the dist/common-components.umd.js)
  • (common-components) (deploy to a private npm rep or a commit/push to a git repo)
  • (application A) yarn upgrade common-components to pull the latest
  • (application A) yarn serve

There has to be a better development cycle than this, right? Or is my real problem that we need to decouple the plugin from our applications better?

THE SOLUTION I WAS HOPING FOR, BUT FAILED

yarn-link or npm-link

I was able to get this to work, but a NPM dependency still resolves to the folder's package.json which has a "main": "dist/common-components.umd.js". This requires me to do a yarn build which removes the file and rebuilds it. When the file is removed, "application A" that is currently running with yarn serve breaks and is unrecoverable. I must shut down the server and do a yarn serve again.

I'm hoping there is a solution out there that tackles this scenario!

Garrett
  • 211
  • 2
  • 5
  • Did you find a solution to this problem yet? – siyb Mar 22 '22 at 08:50
  • Not a great solution yet. We ended up using "yalc", which has to rebuild the entire dependency, push the dependency to the other projects ... but it does auto-reload. The problem with this is it takes 50-60 seconds to build the dependency. Not ideal when you are wanting to see changes quickly. – Garrett Mar 23 '22 at 17:17
  • Garret: we have now started using Vite, which does not seem to have these issues ;) – siyb Mar 28 '22 at 12:55

1 Answers1

0

I've done that kind of setup a while ago thanks to yalc.

It was essentially:

  • work on your own package, setup it (with yalc link if I remember properly)
  • when an update was done on the package, we had it to automatically yalc publish --push --changed like with a linter
  • you can use a pre-push git hook to babelify your package
  • on the host main app, we had a nodemon running to check if yalc published any changes, and if it was the case, simply reload the app
  • on main app still, we used a git hook on pull to have it fetching the latest changes on the yalc.lock store (with yalc update)

I did it a while ago so I don't remember it super well but it was working pretty well as far as I remember, just need to run 2 servers (one on the package to publish and one on your main app to fetch the changes) on top of your other services. Still works better than it's yarn or npm links.

kissu
  • 40,416
  • 14
  • 65
  • 133