Does webpack support sequential watcher/dev-server startup?

[sweco-dkhmaa]

We have a project that we are currently restructuring. Our project is a monorepo with purely client-side code, separated into a lot of packages where some of them are running module federation.

Some of our packages might look like this:

• Host
• Remote 1
• Remote 2
• Component 1
• Component 2
• SharedConfig
• SharedBase

Tried to draw a dependency diagram.

The 2 striped lines are because of federated modules. Theses are not strictly needed during the build process. Every package is depending on both SharedConfig and SharedBase. The globe is dev-servers and the boxes are watchers.

We are using yarn workspaces to organize and select which projects to start, using their workspace foreach cmd. Host and remotes will be running locally on a webpack-dev-server and the other projects will be running with a webpack watcher. All packages are built separately before consumed, and we are very interested in keeping it that way.

When using yarn workspaces foreach cmd, we only have the option to start all in parallel. As starting them in sequence will stop at the first one, since the watcher or dev-server only returns when they are stopped again. This makes for a lot of errors in the console as we run in to instances where a package tries to consume a half-built package. My initial though was that webpack's watchers/dev-servers would rebuild when the half-built package was fully built. But it seems that is not the case.

Ideally we would like to start the watchers/dev-servers sequentially. So starting from the package without any dependencies, and working its way up. And only starting the next when the project is fully built.

I've experimented with the Webpack node api, and seems like we can do that in a custom setup. But i can't believe we are the first to encounter this issue. We would like to stick with yarn, but are open to move to another tool if absolutely necessary.

[alexander-akait]

I've experimented with the Webpack node api, and seems like we can do that in a custom setup. But i can't believe we are the first to encounter this issue. We would like to stick with yarn, but are open to move to another tool if absolutely necessary.

Yes, it is a good idea to write custom startup script in your case

[sweco-dkhmaa]

Thanks for the confirmation. I have gotten it to work in a custom setup, running each package in a node child process.

I'll see if it get the time to trim it down and post, for anyone with the same question.