You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Snowpack has a --config flag, so you could run snowpack build --config [app A]/snowpack.config.js && snowpack build --config [appB]/snowpack.config.js to build multiple apps for production at once.
You could also use the concurrently package along with the --config and --watch flags to watch 2 apps simultaneously (or more!).
At first glance, this seems like a great plan: concurrently looks like a fantastic tool, and this is a clean and simple way to separate distinct Javascript builds within a project. Unfortunately, for an application with a (hypothetical) structure like this:
… running a separate build or dev instance for each bundle will rebuild files from /app/sharedn times, and using --hmr will require binding to n different ports (which also implies needing to map bundles to ports in the application, expose ports via Docker, etc.).
If the bundles all shared the same JS and CSS processing configuration, this would be easily managed by simply mounting each bundle. It's trivial to make dynamic using Node's glob package, and everything runs in a single process (aside: and only builds shared content once?). If they do not share the same configuration (in my case, it would be impractical to impose that requirement), we lose out on those benefits.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
(From #1116)
At first glance, this seems like a great plan:
concurrently
looks like a fantastic tool, and this is a clean and simple way to separate distinct Javascript builds within a project. Unfortunately, for an application with a (hypothetical) structure like this:… running a separate
build
ordev
instance for each bundle will rebuild files from/app/shared
n times, and using--hmr
will require binding to n different ports (which also implies needing to map bundles to ports in the application, expose ports via Docker, etc.).If the bundles all shared the same JS and CSS processing configuration, this would be easily managed by simply
mount
ing each bundle. It's trivial to make dynamic using Node'sglob
package, and everything runs in a single process (aside: and only buildsshared
content once?). If they do not share the same configuration (in my case, it would be impractical to impose that requirement), we lose out on those benefits.Beta Was this translation helpful? Give feedback.
All reactions