@vltpkg/tar 0.0.0-3 → 0.0.0-4

package/README.md

@@ -2,26 +2,27 @@
 
 # @vltpkg/tar
 
-A library for unpacking JavaScript package tarballs (gzip-compressed or raw) into a specified folder.
+A library for unpacking JavaScript package tarballs (gzip-compressed
+or raw) into a specified folder.
 
-**[Usage](#usage)**
-·
-**[Caveats](#caveats)**
+**[Usage](#usage)** · **[Caveats](#caveats)**
 
 ## Overview
 
-If you are unpacking anything other than npm packages, in precisely the way that [vlt](https://vlt.sh) does, then this is
-probably not what you're looking for.
+If you are unpacking anything other than npm packages, in precisely
+the way that [vlt](https://vlt.sh) does, then this is probably not
+what you're looking for.
 
-For a very complete and battle-tested generic tar implementation in JavaScript, see [node-tar](http://npm.im/tar).
+For a very complete and battle-tested generic tar implementation in
+JavaScript, see [node-tar](http://npm.im/tar).
 
 ## Usage
 
 ### unpack(tarData, targetFolder)
 
 Pass your gzip-compressed or raw uncompressed JavaScript package
-tarball in a Buffer (or Uint8Array, or ArrayBuffer slice) into
-the function, along with the folder you want to drop it in.
+tarball in a Buffer (or Uint8Array, or ArrayBuffer slice) into the
+function, along with the folder you want to drop it in.
 
 It will unpack as fast as possible, using synchronous I/O.
 
@@ -38,14 +39,13 @@ unpack(unzipped, 'node_modules/target')
 
 ### `class Pool`
 
-Create a pool of worker threads which will service unpack
-requests in parallel.
+Create a pool of worker threads which will service unpack requests in
+parallel.
 
 New requests that get added will be assigned to workers as those
-workers become available. When a worker completes its task, and
-there are no more tasks to assign, it is terminated. If not
-enough workers are available to service requests, then new ones
-will be spawned.
+workers become available. When a worker completes its task, and there
+are no more tasks to assign, it is terminated. If not enough workers
+are available to service requests, then new ones will be spawned.
 
 #### `pool.jobs`
 
@@ -66,29 +66,27 @@ completed.
 
 #### `pool.unpack(tarData: Buffer, target: string) => Promise<void>`
 
-Unpack the supplied Buffer of data into the target folder,
-using synchronous I/O in a worker thread.
+Unpack the supplied Buffer of data into the target folder, using
+synchronous I/O in a worker thread.
 
 Promise resolves when this unpack request has been completed.
 
 ## Caveats
 
-As stated above, **this is not a general purpose tar
-implementation**. It does not handle symbolic links at all (those
-aren't allowed in JavaScript packages). It does not respect
-uid/gid ownership flags. All files are with a mode of `0o644` (or
-`0o666` on Windows - technically it's `0o666` xor'ed with the
-system umask, so that'll often be `0o664` on linux systems). All
-directories are created with a mode of `0o755` by default (with
-the same windows/umask caveats as files, so maybe that's `0o775`
-or some such.) All ctime/mtime/atime/birthtime values will just
-be left as the current time.
-
-It does not do any of the binary linking or other stuff that a
-package manager will need to do. It _just_ does the unpack, as
-ruthlessly fast as possible, and that's all.
-
-Synchronous IO is used because that's faster and requires less
-CPU utilization. The `Pool` class manages multiple worker threads
-doing this work, so faster sync IO for the whole thing is much
-more optimal.
+As stated above, **this is not a general purpose tar implementation**.
+It does not handle symbolic links at all (those aren't allowed in
+JavaScript packages). It does not respect uid/gid ownership flags. All
+files are with a mode of `0o644` (or `0o666` on Windows - technically
+it's `0o666` xor'ed with the system umask, so that'll often be `0o664`
+on linux systems). All directories are created with a mode of `0o755`
+by default (with the same windows/umask caveats as files, so maybe
+that's `0o775` or some such.) All ctime/mtime/atime/birthtime values
+will just be left as the current time.
+
+It does not do any of the binary linking or other stuff that a package
+manager will need to do. It _just_ does the unpack, as ruthlessly fast
+as possible, and that's all.
+
+Synchronous IO is used because that's faster and requires less CPU
+utilization. The `Pool` class manages multiple worker threads doing
+this work, so faster sync IO for the whole thing is much more optimal.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@vltpkg/tar",
   "description": "An extremely limited and very fast tar extractor",
-  "version": "0.0.0-3",
+  "version": "0.0.0-4",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/vltpkg/vltpkg.git",
@@ -24,7 +24,7 @@
   "dependencies": {
     "rimraf": "^6.0.1",
     "tar": "^7.4.3",
-    "@vltpkg/error-cause": "0.0.0-3"
+    "@vltpkg/error-cause": "0.0.0-4"
   },
   "devDependencies": {
     "@eslint/js": "^9.20.0",