Redesign crx API

[thom4parisot]

crx(['/path/to/manifest.json', '/path/to/**.js', '!/path/to/node_modules'], { options })
  .then(crx => {
    crx.options; // { options }
    crx.included; // => ['manifest.json', 'index.js'];
    crx.excluded; // => ['node_modules/jquery/dist/jquery.js', ...]
    crx.mapping; // => { '/path/to/manifest.json' => 'manifest.json', ... }

    crx.archive()
      .then(archive => archive.pipe(fs.createWriteFile('extension.zip')))
      .then(archive => crx.sign(archive))
      .then(stream => stream.pipe(fs.createWriteFile('extension.crx')));
  });

API

• keys API
• create Public Key
• read Private Key
• generate Private Key
• crx API
• crx(files, options) file selection constructor
• pack().then(archive)
• sign(archive).then(crx)
• autoupdate API
• getManifest(appId)

Under the hood we need to have:

• generateAppId(publicKey).then(appId)
• generateSignature(archive).then(signature)

Are dropped:

• writeFile
• load
• options.rootDirectory, options.path and options.src

Options

• ignore (defaults to ['*.pem', '.git', '*.crx'])
• publicKey
• privateKey (optional, to use #sign() only)
• autoupdate
  • codebase
  • prodversionmin

[ahwayakchih]

I'm not sure that separating pack and sign is really needed. Without signing, pack becomes basically just a ZIP command, and there are already other modules for that.

Also, while this:

.then(stream => stream.pipe(fs.createWriteFile('extension.crx')));

looks quite nice, it would require keeping everything in memory. I thought the goal was to stream data without caching it.
AFAIK, there is no way to target specific position earlier in stream while piping. CRX header is at the beginning of a file, but to create header data, one has to know all the ZIP data to be written after the header.
In my version of CRX3 module there is a crx3stream but it works like a file write stream, i.e, not possible to pipe it to a next stream, because it "jumps over" header position, writes incoming ZIP stream while generating it's hash, after which it generates header data and writes it at the beginning of the file. So it does not have to keep whole ZIP in memory, but it does not allow to pipe CRX stream elsewhere (i mean, without reopening the file and reading from it later).