In memory build/serve

[ashubham]

Rollup is being slow for me in development, it takes around ~20s for incremental builds in the 'watch' mode with cache.

Feature Use Case

If we could prevent outputting the incremental bundle to disk, instead serve it via another plugin (rollup-plugin-serve-inmemory ?). Just like webpack does. I think it will save considerable time for each iteration.

Feature Proposal

Do not output to disk, provide plugin hooks to enable development of a plugin which could serve the bundles from memory.

[lukastaegert]

This option has been added to support this workflow: https://rollupjs.org/guide/en/#watchskipwrite

Otherwise, the existing hooks should be sufficient. You will not save a lot, though.

[ashubham]

@lukastaegert Thanks for that.

Are there any other new developments in the perf area with rollup 2.0 ? Want to make sure I am doing the best practices for dev mode. My team's frustration with the build times is growing and I absolutely want to continue using Rollup.

[lukastaegert]

Unfortunately not, and dev performance is just one of a huge list of stuff I want to work, so no promises for any improvements soon. But if you really want a quantum leap in dev experience, maybe switching to a no-bundler-in-dev setup would work for you? There are quite a few tools that could make this work, but of course the devil is in the details.

• Snowpack, if set up correctly, can transpile all your dependencies to ES modules, making them runnable in the browser. Basically a replacement for @rollup/plugin-commonjs. They have guides for many setups and frameworks. Personally, I had very good experiences creating a TypeScript-React app where I just ran tsc --watch during development (which is REALLY fast) using snow-packed dependencies.
• es-dev-server is able to use Rollup's own @rollup/plugin-node-resolve to resolve bare module imports. Beyond that, it is highly configurable with middlewares etc.

So the question would be how much you depend on other Rollup plugin functionality. Things such as direct CSS imports might be fixable by adding a middleware to es-dev-server. But if you are using a special styling solution, the middleware would need to do some work. So the question is what your frontend stack is here.

[ashubham]

Thanks again for your reply.

I ham aware of Snowpack and es-dev-server. I even published a middleware for es-dev-server where it used rollup-plugin-commonjs to serve commonjs modules (if you are not using Snowpack). Can be found here https://github.com/ashubham/es-dev-commonjs-transformer.

Yeah these are great tools but unfortunately our build has some more parts like scss, CSS Modules, graphql imports etc. So it needs a bit of work before I could use this. And I do not want to build anything custom for us because it brings along maintenance/documentation overhead.

[daKmoR]

I am probably biased but I am really enjoying the no-bundler-in-dev setup 👍
instant startup times and it keeps you in line with thePlatform (e.g. the browser) to not go crazy as for example importing of css/json/... is not possible in the browser right now so it's also "not possible" in a buildless dev setup.

None the less whenever you go to production you need an actual build and that is where rollup shines. Again if you only use what is possible in the browser then this part is a breeze 👍

I, however, can fully relate if that seems "impossible" for many cases as commonjs or other non standard, non browser features (like importing scss, css, ...) are heavily used. This sort of locks you into your build process where you can't easily switch to another build tool or have no build tool 😅

For commonjs you can sort of solve it by asking for es module versions or publish it automatically via @esm-bundle... see more details here: https://medium.com/@joeldenning/an-esm-bundle-for-any-npm-package-5f850db0e04d

for other special feature you will need to "pay the bill" by always requireing a build tool or by needing to reimplementn these features multiple times (for dev server, testing, building for production, ...)

[lukastaegert]

There would be ways to add a fast development experience to Rollup but as I said, there are quite a few other equally important topics I want to tackle first, and it would not be trivial. But yes, I think about performance a lot.

[paulmillr]

I would love to help with that. In particular, looking for ways to include rollup in https://brunch.io. Brunch is one of the oldest web app builders around, it was there even before Grunt. I just can't stand complexity of every other bundler.

Rollup is awesome for tree shaking. Brunch is very fast and simple. Snowpack, for example, requires some weird npm scripts — not great.