Three caching questions

[arxpoetica]

The JS API allows for caching: https://github.com/rollup/rollup/wiki/JavaScript-API#cache

The documentation on this is pretty sparse.

First, it's not clear, for example, how this caching would be useful from an API, since a JS file with caching might need to be watched and/or restarted with something like nodemon, hence, rendering caching useless since the app restarts and reloads everything anyway. Or is it somehow cached offline? Am I making sense?

Next up, is the cache option also available in a regular (non API) rollup.config.js file? If I, for example, throw it in a config file, then run rollup -c --watch will it do the caching magic? Or is this an API-only thing?

Finally, what exactly is getting cached?

[Rich-Harris]

The idea is that the bundle can be serialized to JSON, so in theory you could save it to disk and pass it in at startup. To be honest I'm not sure off the top of my head if that actually works... The primary use case is incremental builds once Rollup has already started.

If you're using rollup.config.js, you don't need to specify anything as an option if you're using the CLI – it Just Works*. The CLI stores the bundle for you and passes it back in on the next rebuild.

Finally, what exactly is getting cached?

The implementation details are subject to change, but basically it caches the source (for comparison), the result of any transformations, and the parsed AST.

[arxpoetica]

That's awesome. 👍

[weepy]

@Rich-Harris it is possible to get it to do this onstart up - i.e. store the cache on disk so that startup is faster ?

[lukastaegert]

The commonjs plugin will not work in such a setup at the moment.