Changelog
13.0.0 (2019-09-25)
The mississippi methods 'to', 'from', 'through', and so on, have been replaced with their Minipass counterparts, and streaming interaction with the file system is done via fs-minipass.
The following modules are of interest here:
minipass The core stream library.
fs-minipass Note that the 'WriteStream' class from fs-minipass is not a Minipass stream, but rather a plain old EventEmitter that duck types as a Writable.
minipass-collect Gather up all the data from a stream. Cacache only uses Collect.PassThrough, which is a basic Minipass passthrough stream which emits a 'collect' event with the completed data just before the 'end' event.
minipass-pipeline Connect one or more streams into a pipe chain. Errors anywhere in the pipeline are proxied down the chain and then up to the Pipeline object itself. Writes go into the head, reads go to the tail. Used in place of pump() and pumpify().
minipass-flush A Minipass passthrough stream that defers its 'end' event until after a flush() method has completed (either calling the supplied callback, or returning a promise.) Use in place of flush-write-stream (aka mississippi.to).
Streams from through2, concat-stream, and the behavior provided by end-of-stream are all implemented in Minipass itself.
Features of interest to cacache, which make Minipass a particularly good fit:
The biggest downside of Minipass is that it lacks some of the internal characteristics of node-core streams, which many community modules use to identify streams. They have no _writableState or _readableState objects, or _read or _write methods. As a result, the is-stream module (at least, at the time of this commit) doesn't recognize Minipass streams as readable or writable streams.
All in all, the changes required of downstream users should be minimal, but are unlikely to be zero. Hence the semver major change.
Changelog
12.0.1 (2019-07-19)
lib/util/infer-owner.js
to
@npmcli/infer-owner
so that it could be more easily used in other parts of the npm CLI.Changelog
12.0.0 (2019-07-15)
Reasoning:
The number one reason to use a uid or gid option was to keep root-owned files from causing problems in the cache. In npm's case, this meant that CLI's ./lib/command.js had to work out the appropriate uid and gid, then pass it to the libnpmcommand module, which had to in turn pass the uid and gid to npm-registry-fetch, which then passed it to make-fetch-happen, which passed it to cacache. (For package fetching, pacote would be in that mix as well.)
Added to that, cacache.rm()
will actually write a file into the
cache index, but has no way to accept an option so that its call to
entry-index.js will write the index with the appropriate uid/gid.
Little ownership bugs were all over the place, and tricky to trace
through. (Why should make-fetch-happen even care about accepting or
passing uids and gids? It's an http library.)
This change allows us to keep the cache from having mixed ownership in any situation.
Of course, this does mean that if you have a root-owned but
user-writable folder (for example, /tmp
), then the cache will try to
chown everything to root.
The solution is for the user to create a folder, make it user-owned, and use that, rather than relying on cacache to create the root cache folder.
If we decide to restore the uid/gid opts, and use ownership inference only when uid/gid are unset, then take care to also make rm take an option object, and pass it through to entry-index.js.