Some of our browserify bundles take over 45 seconds to build. While watchify is great for development, building all of our bundles is a significant amount of time on our build machines and deployment server where it doesn't make sense to have a long running process.
It would be immensely valuable to have the watchify cache persisted to disk on process exit (or perhaps on some interval). That would enable multiple watchify instances running in parallel (for different bundles) to all build quickly since they could load the cache from the watchify run on the previous build.
It could also streamline the speed if you generate browserify bundles and run karma. The time required for bundling files for karma would be significantly less as well.
Some of our browserify bundles take over 45 seconds to build. While watchify is great for development, building all of our bundles is a significant amount of time on our build machines and deployment server where it doesn't make sense to have a long running process.
It would be immensely valuable to have the watchify cache persisted to disk on process exit (or perhaps on some interval). That would enable multiple watchify instances running in parallel (for different bundles) to all build quickly since they could load the cache from the watchify run on the previous build.
It could also streamline the speed if you generate browserify bundles and run karma. The time required for bundling files for karma would be significantly less as well.
This is aligned with the work @Xanderite did in https://github.com/substack/watchify/pull/313 and #306 as well as @jsdf's work in https://github.com/jsdf/browserify-incremental