I'm not knowledgable of the initiative or NPM package, and Blubber doesn't really have an opinion about this other than it's best practice to have the source of runtime files (application + linked/importable libraries) be read-only, but here's my suggestion from reading the following part of the documentation:

findCacheDir(options?)
Finds the cache directory using the supplied options. The algorithm checks for the CACHE_DIR environmental variable and uses it if it is not set to true, false, 1 or 0. If one is not found, it tries to find a package.json file, searching every parent directory of the cwd specified (or implied from other options). It returns a string containing the absolute path to the cache directory, or undefined if package.json was never found or if the node_modules directory is unwritable.

I would say an explicit setting of CACHE_DIR to somewhere writable (e.g. /tmp/node_cache) would be your best bet. I'm not opposed to adding this as a default behavior of Blubber's Node builder if you think this is a prevalent enough package used in the Node world.

Hi @dduvall,

thanks for the response.

best practice to have the source of runtime files (application + linked/importable libraries) be read-only

I very much agree. It's debatable if a cache directory matches this description but its (IMO questionable) default placement under node_modules/ of course makes for its policies to be applied to this directory as well - unless specified otherwise.

explicit setting of CACHE_DIR to somewhere writable (e.g. /tmp/node_cache) would be your best bet

That's what we actually do (commit) and where the question originates. We can work around it but thought: let's file this as it's a bit arbitrary to configure it in the application (configuring infrastructure in a higher layer) and others may run into it too.

I'm not opposed to adding this as a default behavior of Blubber's Node builder if you think this is a prevalent enough package used in the Node world.

That sounds awesome. It's indeed a compromise between adding (potentially needless) complexity to blubber and making (potentially popular) node paradigms easy to use. I don't have a strong opinion of my own. Looking at the showcased adopters there seem to be some rather popular players (e.g. storybook, babel-loader, eslint-loader) but I'm not sure how to weigh the pros and cons. I'm also not sure if the caching is super relevant for the blubber use case or if it were actually ok if no such caching at all happened in this case and, in this particular use case, the package (storybook) just did not fail gracefully enough trying to write. I think I'd be ok with any decision by the blubber team taken consciously in the awareness that this initiative even exists.

Thanks

FTR: I'm not sure what the status of this is, but the repository that made us open this ticket is now being archived: T309872: Archive wikibase-vuejs-components library repository.

I (author of the ticket) do not have stake in this and, I guess, neither has WMDE anymore. Maybe with the issue written down and linked to the blubber board this ticket has served its purpose (discoverability). I don't object to closing it.