level-supports
Advanced tools
Comparing version 3.0.0 to 4.0.0
| # Changelog | ||
| ## [4.0.0] - 2022-01-02 | ||
| ### Removed | ||
| - **Breaking:** drop Node.js 10 ([`ad1c533`](https://github.com/Level/supports/commit/ad1c533)) (Vincent Weevers) | ||
| - Remove unused properties ([`c894eba`](https://github.com/Level/supports/commit/c894eba)) (Vincent Weevers). | ||
| ### Fixed | ||
| - Align docs with `abstract-level` ([`c894eba`](https://github.com/Level/supports/commit/c894eba)) (Vincent Weevers). | ||
| ## [3.0.0] - 2021-11-07 | ||
| _No longer compatible with `abstract-leveldown` or its dependents._ | ||
| _No longer compatible with `abstract-leveldown`, `levelup` or their dependents._ | ||
@@ -61,2 +72,4 @@ ### Changed | ||
| [4.0.0]: https://github.com/Level/supports/releases/tag/v4.0.0 | ||
| [3.0.0]: https://github.com/Level/supports/releases/tag/v3.0.0 | ||
@@ -63,0 +76,0 @@ |
146
index.d.ts
@@ -0,27 +1,163 @@ | ||
| /** | ||
| * Given zero or more manifest objects, returns a merged and enriched manifest object | ||
| * that has truthy properties for each of the features listed in {@link IManifest}. | ||
| * | ||
| * @param manifests Partial manifest(s) to merge. | ||
| */ | ||
| export function supports (...manifests: Array<Partial<IManifest>>): IManifest | ||
| /** | ||
| * Describes the abilities of an | ||
| * [`abstract-level`](https://github.com/Level/abstract-level) database. Support matrices | ||
| * for known `abstract-level` implementations can be found in | ||
| * [`level-supports`](https://github.com/Level/supports#features). | ||
| */ | ||
| export interface IManifest { | ||
| bufferKeys: boolean | ||
| /** | ||
| * Does the database have snapshot guarantees? Meaning that reads are unaffected by | ||
| * simultaneous writes. For example, an iterator should read from a snapshot of the | ||
| * database, created at the time `db.iterator()` was called. This means the iterator | ||
| * will not see the data of simultaneous write operations. | ||
| */ | ||
| snapshots: boolean | ||
| /** | ||
| * Does data survive after process (or environment) exit? | ||
| */ | ||
| permanence: boolean | ||
| /** | ||
| * Do iterators support | ||
| * [`seek(..)`](https://github.com/Level/abstract-level/#iteratorseektarget-options)? | ||
| */ | ||
| seek: boolean | ||
| /** | ||
| * Does the database support `db.clear()`? Always true since `abstract-level@1`. | ||
| */ | ||
| clear: boolean | ||
| /** | ||
| * Does the database support `db.getMany()`? Always true since `abstract-level@1`. | ||
| */ | ||
| getMany: boolean | ||
| /** | ||
| * Does the database have a `keys([options])` method that returns a key iterator? Also | ||
| * implies support of `iterator#mode`. | ||
| * | ||
| * @experimental | ||
| */ | ||
| keyIterator: boolean | ||
| /** | ||
| * Does the database have a `values([options])` method that returns a key iterator? | ||
| * Also implies support of `iterator#mode`. | ||
| * | ||
| * @experimental | ||
| */ | ||
| valueIterator: boolean | ||
| /** | ||
| * Do iterators have a `nextv(size[, options][, callback])` method? | ||
| * | ||
| * @experimental | ||
| */ | ||
| iteratorNextv: boolean | ||
| /** | ||
| * Do iterators have a `all([options][, callback])` method? | ||
| * | ||
| * @experimental | ||
| */ | ||
| iteratorAll: boolean | ||
| /** | ||
| * Does the database have a | ||
| * [`status`](https://github.com/Level/abstract-level/#dbstatus) property? Always true | ||
| * since `abstract-level@1`. | ||
| */ | ||
| status: boolean | ||
| idempotentOpen: boolean | ||
| passiveOpen: boolean | ||
| serialize: boolean | ||
| /** | ||
| * Does `db.open()` and the database constructor support this option? | ||
| */ | ||
| createIfMissing: boolean | ||
| /** | ||
| * Does `db.open()` and the database constructor support this option? | ||
| */ | ||
| errorIfExists: boolean | ||
| /** | ||
| * Can operations like `db.put()` be called without explicitly opening the db? Like so: | ||
| * | ||
| * ```js | ||
| * const db = new Level() | ||
| * await db.put('key', 'value') | ||
| * ``` | ||
| */ | ||
| deferredOpen: boolean | ||
| openCallback: boolean | ||
| /** | ||
| * Do all database methods (that don't otherwise have a return value) support promises, | ||
| * in addition to callbacks? Such that, when a callback argument is omitted, a promise | ||
| * is returned: | ||
| * | ||
| * ```js | ||
| * db.put('key', 'value', callback) | ||
| * await db.put('key', 'value') | ||
| * ``` | ||
| */ | ||
| promises: boolean | ||
| /** | ||
| * Does database have the methods `createReadStream`, `createKeyStream` and | ||
| * `createValueStream`, following the API documented in `levelup`? For `abstract-level` | ||
| * databases, a standalone module called | ||
| * [`level-read-stream`](https://github.com/Level/read-stream) is available. | ||
| */ | ||
| streams: boolean | ||
| /** | ||
| * Which encodings (by name) does the database support, as indicated by nested | ||
| * properties? For example: | ||
| * | ||
| * ```js | ||
| * { utf8: true, json: true } | ||
| * ``` | ||
| */ | ||
| encodings: Record<string, boolean> | ||
| /** | ||
| * Which events does the database emit, as indicated by nested properties? For example: | ||
| * | ||
| * ```js | ||
| * if (db.supports.events.put) { | ||
| * db.on('put', listener) | ||
| * } | ||
| * ``` | ||
| */ | ||
| events: Record<string, boolean> | ||
| /** | ||
| * Declares support of additional methods, that are not part of the `abstract-level` | ||
| * interface. In the form of: | ||
| * | ||
| * ```js | ||
| * { | ||
| * foo: true, | ||
| * bar: true | ||
| * } | ||
| * ``` | ||
| * | ||
| * Which says the db has two methods, `foo` and `bar`. It might be used like so: | ||
| * | ||
| * ```js | ||
| * if (db.supports.additionalMethods.foo) { | ||
| * db.foo() | ||
| * } | ||
| * ``` | ||
| */ | ||
| additionalMethods: Record<string, boolean> | ||
| } |
@@ -7,3 +7,2 @@ 'use strict' | ||
| return Object.assign(manifest, { | ||
| bufferKeys: manifest.bufferKeys || false, | ||
| snapshots: manifest.snapshots || false, | ||
@@ -19,9 +18,5 @@ permanence: manifest.permanence || false, | ||
| status: manifest.status || false, | ||
| idempotentOpen: manifest.idempotentOpen || false, | ||
| passiveOpen: manifest.passiveOpen || false, | ||
| serialize: manifest.serialize || false, | ||
| createIfMissing: manifest.createIfMissing || false, | ||
| errorIfExists: manifest.errorIfExists || false, | ||
| deferredOpen: manifest.deferredOpen || false, | ||
| openCallback: manifest.openCallback || false, | ||
| promises: manifest.promises || false, | ||
@@ -28,0 +23,0 @@ streams: manifest.streams || false, |
| { | ||
| "name": "level-supports", | ||
| "version": "3.0.0", | ||
| "description": "Create a manifest describing the abilities of a levelup or abstract-leveldown db", | ||
| "version": "4.0.0", | ||
| "description": "Create a manifest describing the abilities of an abstract-level database", | ||
| "license": "MIT", | ||
@@ -20,13 +20,13 @@ "scripts": { | ||
| "devDependencies": { | ||
| "@types/node": "^16.11.6", | ||
| "@voxpelli/tsconfig": "^3.0.0", | ||
| "airtap": "^4.0.3", | ||
| "@types/node": "^17.0.6", | ||
| "@voxpelli/tsconfig": "^3.1.0", | ||
| "airtap": "^4.0.4", | ||
| "airtap-playwright": "^1.0.1", | ||
| "faucet": "^0.0.1", | ||
| "hallmark": "^3.1.0", | ||
| "hallmark": "^4.0.0", | ||
| "nyc": "^15.1.0", | ||
| "standard": "^16.0.3", | ||
| "tape": "^5.0.1", | ||
| "ts-standard": "^10.0.0", | ||
| "typescript": "^4.4.4" | ||
| "tape": "^5.4.0", | ||
| "ts-standard": "^11.0.0", | ||
| "typescript": "^4.5.4" | ||
| }, | ||
@@ -47,4 +47,4 @@ "repository": { | ||
| "engines": { | ||
| "node": ">=10" | ||
| "node": ">=12" | ||
| } | ||
| } |
417
README.md
| # level-supports | ||
| > **Create a manifest describing the abilities of a [`levelup`](https://github.com/Level/levelup) or [`abstract-leveldown`](https://github.com/Level/abstract-leveldown) db.** | ||
| **Create a manifest describing the abilities of an [`abstract-level`](https://github.com/Level/abstract-level) database.** No longer compatible with [`levelup`](https://github.com/Level/levelup) or [`abstract-leveldown`](https://github.com/Level/abstract-leveldown) since version 3.0.0. | ||
@@ -9,6 +9,6 @@ [![level badge][level-badge]](https://github.com/Level/awesome) | ||
| [](https://github.com/Level/supports/actions/workflows/test.yml) | ||
| [](https://codecov.io/gh/Level/supports) | ||
| [](https://standardjs.com) | ||
| [](https://codecov.io/gh/Level/supports) | ||
| [](https://standardjs.com) | ||
| [](https://common-changelog.org) | ||
| [](https://opencollective.com/level) | ||
| [](https://opencollective.com/level) | ||
@@ -21,5 +21,5 @@ ## Usage | ||
| db.supports = supports({ | ||
| bufferKeys: true, | ||
| additionalMethods: { | ||
| approximateSize: true | ||
| permanence: false, | ||
| encodings: { | ||
| utf8: true | ||
| } | ||
@@ -35,6 +35,2 @@ }) | ||
| } | ||
| if (db.supports.bufferKeys && db.supports.promises) { | ||
| await db.put(Buffer.from('key'), 'value') | ||
| } | ||
| ``` | ||
@@ -46,14 +42,11 @@ | ||
| Given zero or more manifest objects, returns a merged and enriched manifest object that has: | ||
| Given zero or more manifest objects, returns a merged and enriched manifest object that has truthy properties for each of the features listed below. | ||
| - Truthy properties for each of the features listed below | ||
| - An `additionalMethods` object | ||
| For future extensibility, the properties are truthy rather than strictly typed booleans. Falsy or absent properties are converted to `false`, other values are allowed: | ||
| ```js | ||
| supports().streams // false | ||
| supports({ streams: true }).streams // true | ||
| supports({ streams: {} }).streams // {} | ||
| supports({ streams: 1 }, { streams: 2 }).streams // 2 | ||
| supports().snapshots // false | ||
| supports({ snapshots: true }).snapshots // true | ||
| supports({ snapshots: {} }).snapshots // {} | ||
| supports({ snapshots: 1 }, { snapshots: 2 }).snapshots // 2 | ||
| ``` | ||
@@ -64,3 +57,3 @@ | ||
| ```js | ||
| if (db.supports.streams) | ||
| if (db.supports.snapshots) | ||
| ``` | ||
@@ -71,3 +64,3 @@ | ||
| ```js | ||
| if (db.supports.streams === true) | ||
| if (db.supports.snapshots === true) | ||
| ``` | ||
@@ -79,34 +72,9 @@ | ||
| ### `bufferKeys` (boolean) | ||
| ### `snapshots` (boolean) | ||
| Does the db support [Buffer](https://nodejs.org/api/buffer.html) keys? May depend on runtime environment as well. Does _not_ include support of other binary types like typed arrays (which is why this is called `bufferKeys` rather than `binaryKeys`). | ||
| Does the database have snapshot guarantees? Meaning that reads are unaffected by simultaneous writes. For example, an iterator should read from a snapshot of the database, created at the time `db.iterator()` was called. This means the iterator will not see the data of simultaneous write operations. | ||
| <details> | ||
| <summary>Support matrix</summary> | ||
| Must be `false` if any of the following is true: | ||
| | Module | Support | | ||
| | :------------------- | :------ | | ||
| | `abstract-leveldown` | ✅ | | ||
| | `leveldown` | ✅ | | ||
| | `rocksdb` | ✅ | | ||
| | `memdown` | ✅ | | ||
| | `level-js` | ✅ | | ||
| | `encoding-down` | ✅ | | ||
| | `deferred-leveldown` | ✅ | | ||
| | `levelup` | ✅ | | ||
| | `level-packager` | ✅ | | ||
| | `level` | ✅ | | ||
| | `level-mem` | ✅ | | ||
| | `level-rocksdb` | ✅ | | ||
| | `subleveldown` | ✅ | | ||
| | `multileveldown` | ✅ | | ||
| | `level-party` | ✅ | | ||
| </details> | ||
| ### `snapshots` (boolean) | ||
| Does the db have snapshot guarantees (meaning that reads are unaffected by simultaneous writes)? Must be `false` if any of the following is true: | ||
| - Reads don't operate on a [snapshot](https://github.com/Level/abstract-leveldown#iterator) | ||
| - Reads don't operate on a snapshot | ||
| - Snapshots are created asynchronously. | ||
@@ -119,3 +87,6 @@ | ||
| | :------------------- | :-------------------------- | | ||
| | `abstract-leveldown` | ✅ | | ||
| | `classic-level` | ✅ | | ||
| | `memory-level` | ✅ | | ||
| | `browser-level` | ✅ (by buffering) | | ||
| | `rocks-level` | ✅ | | ||
| | `leveldown` | ✅ | | ||
@@ -140,7 +111,7 @@ | `rocksdb` | ✅ | | ||
| Does data survive after process exit? Is `false` for e.g. [`memdown`](https://github.com/Level/memdown), typically `true`. | ||
| Does data survive after process (or environment) exit? Typically true. False for [`memory-level`](https://github.com/Level/memory-level) and [`memdown`](https://github.com/Level/memdown). | ||
| ### `seek` (boolean) | ||
| Do iterators support [`seek(..)`](https://github.com/Level/abstract-leveldown/#iteratorseektarget)? | ||
| Do iterators support [`seek(..)`](https://github.com/Level/abstract-level/#iteratorseektarget-options)? | ||
@@ -150,19 +121,25 @@ <details> | ||
| | Module | Support | | ||
| | :------------------- | :------------- | | ||
| | `abstract-leveldown` | ✅ 6.0.0 | | ||
| | `leveldown` | ✅ 1.2.0 | | ||
| | `rocksdb` | ✅ 1.0.0 | | ||
| | `memdown` | ✅ 4.1.0 | | ||
| | `level-js` | ❌ | | ||
| | `encoding-down` | ✅ 6.1.0 | | ||
| | `deferred-leveldown` | ✅ 5.1.0 | | ||
| | `levelup` | ✅ n/a | | ||
| | `level-packager` | ✅ n/a | | ||
| | `level` | ❌ (`level-js`) | | ||
| | `level-mem` | ✅ 4.0.0 | | ||
| | `level-rocksdb` | ✅ 1.0.0 | | ||
| | `subleveldown` | ✅ 4.1.0 | | ||
| | `multileveldown` | ❌ | | ||
| | `level-party` | ❌ | | ||
| | Module | Support | | ||
| | :------------------- | :------------------ | | ||
| | `abstract-level` | ✅ 1.0.0 | | ||
| | `classic-level` | ✅ 1.0.0 | | ||
| | `memory-level` | ✅ 1.0.0 | | ||
| | `browser-level` | ❌ | | ||
| | `rocks-level` | ✅ 1.0.0 | | ||
| | `abstract-leveldown` | ✅ 6.0.0 | | ||
| | `leveldown` | ✅ 1.2.0 | | ||
| | `rocksdb` | ✅ 1.0.0 | | ||
| | `memdown` | ✅ 4.1.0 | | ||
| | `level-js` | ❌ | | ||
| | `encoding-down` | ✅ 6.1.0 | | ||
| | `deferred-leveldown` | ✅ 5.1.0 | | ||
| | `levelup` | ✅ n/a | | ||
| | `level-packager` | ✅ n/a | | ||
| | `level@7` | ❌ (`level-js`) | | ||
| | `level@8` | ❌ (`browser-level`) | | ||
| | `level-mem` | ✅ 4.0.0 | | ||
| | `level-rocksdb` | ✅ 1.0.0 | | ||
| | `subleveldown` | ✅ 4.1.0 | | ||
| | `multileveldown` | ❌ | | ||
| | `level-party` | ❌ | | ||
@@ -173,3 +150,3 @@ </details> | ||
| Does db support [`db.clear(..)`](https://github.com/Level/abstract-leveldown/#dbclearoptions-callback)? | ||
| Does the database support `db.clear()`? Always true since `abstract-level@1`. | ||
@@ -181,19 +158,20 @@ <details> | ||
| | Module | Support | Optimized | | ||
| | :------------------- | :------ | :------------ | | ||
| | `abstract-leveldown` | ✅ 6.1.0 | n/a | | ||
| | `leveldown` | ✅ 5.2.0 | ✅ 6.0.3 | | ||
| | `rocksdb` | ✅ 4.1.0 | ❌ | | ||
| | `memdown` | ✅ 5.0.0 | ✅ 6.1.1 | | ||
| | `level-js` | ✅ 5.0.0 | ✅ 5.0.0 | | ||
| | `encoding-down` | ✅ 6.2.0 | n/a | | ||
| | `deferred-leveldown` | ✅ 5.2.0 | n/a | | ||
| | `levelup` | ✅ 4.2.0 | n/a | | ||
| | `level-packager` | ✅ 5.0.3 | n/a | | ||
| | `level` | ✅ 6.0.0 | ✅ 7.0.1 | | ||
| | `level-mem` | ✅ 5.0.1 | ✅ 6.0.1 | | ||
| | `level-rocksdb` | ✅ 5.0.0 | ❌ (`rocksdb`) | | ||
| | `subleveldown` | ✅ 4.2.1 | ✅ 4.2.1 | | ||
| | `multileveldown` | ✅ 5.0.0 | ✅ 5.0.0 | | ||
| | `level-party` | ✅ 5.1.0 | ✅ 5.1.0 | | ||
| | Module | Support | Optimized | | ||
| | :------------------------------ | :------ | :-------- | | ||
| | `abstract-level` and dependents | ✅ 1.0.0 | ✅ 1.0.0 | | ||
| | `abstract-leveldown` | ✅ 6.1.0 | n/a | | ||
| | `leveldown` | ✅ 5.2.0 | ✅ 6.0.3 | | ||
| | `rocksdb` | ✅ 4.1.0 | ✅ 5.2.0 | | ||
| | `memdown` | ✅ 5.0.0 | ✅ 6.1.1 | | ||
| | `level-js` | ✅ 5.0.0 | ✅ 5.0.0 | | ||
| | `encoding-down` | ✅ 6.2.0 | n/a | | ||
| | `deferred-leveldown` | ✅ 5.2.0 | n/a | | ||
| | `levelup` | ✅ 4.2.0 | n/a | | ||
| | `level-packager` | ✅ 5.0.3 | n/a | | ||
| | `level` | ✅ 6.0.0 | ✅ 7.0.1 | | ||
| | `level-mem` | ✅ 5.0.1 | ✅ 6.0.1 | | ||
| | `level-rocksdb` | ✅ 5.0.0 | ✅ 5.0.0 | | ||
| | `subleveldown` | ✅ 4.2.1 | ✅ 4.2.1 | | ||
| | `multileveldown` | ✅ 5.0.0 | ✅ 5.0.0 | | ||
| | `level-party` | ✅ 5.1.0 | ✅ 5.1.0 | | ||
@@ -204,12 +182,4 @@ </details> | ||
| Does db have a [`status`](https://github.com/Level/abstract-leveldown/#dbstatus) property? That returns a string value that is one of: | ||
| Does the database have a [`status`](https://github.com/Level/abstract-level/#dbstatus) property? Always true since `abstract-level@1`. | ||
| - `new` - newly created, not opened or closed | ||
| - `opening` - waiting for the store to be opened | ||
| - `open` - successfully opened the store | ||
| - `closing` - waiting for the store to be closed | ||
| - `closed` - store has been successfully closed. | ||
| The `new` status should be avoided. It is being phased out in favor of an initial status of `closed`. | ||
| ### `deferredOpen` (boolean) | ||
@@ -220,69 +190,9 @@ | ||
| ```js | ||
| var db = level() | ||
| db.put('key', 'value', callback) | ||
| const db = new Level() | ||
| await db.put('key', 'value') | ||
| ``` | ||
| Rather than: | ||
| ```js | ||
| var db = level() | ||
| db.open(function (err) { | ||
| if (err) throw err | ||
| db.put('key', 'value', callback) | ||
| }) | ||
| ``` | ||
| ### `idempotentOpen` (boolean) | ||
| Are `db.open()` and `db.close()` idempotent and safe, such that: | ||
| 1. Calling `open()` or `close()` twice has the same effect as calling it once | ||
| 2. If both `open()` and `close()` are called in succession while a previous call has not yet completed, the last call dictates the final `status` and all earlier calls yield an error if they oppose the final `status`. | ||
| 3. Callbacks are called in the order that the `open()` or `close()` calls were made. | ||
| 4. Callbacks are not called until any pending state changes are done, meaning that `status` is not (or no longer) 'opening' or 'closing'. | ||
| 5. If events are supported, they are emitted before callbacks are called, because event listeners may result in additional pending state changes. | ||
| 6. If events are supported, the 'open' and 'closed' events are not emitted if there are pending state changes or if the initial `status` matches the final `status`. They communicate a changed final `status` even though the (underlying) db may open and close multiple times before that. This avoids emitting (for example) an 'open' event while `status` is 'closing'. | ||
| For example: | ||
| 1. In a sequence of calls like `open(); close(); open()` the final `status` will be 'open', the second call will receive an error, an 'open' event is emitted once, no 'closed' event is emitted, and all callbacks will see that `status` is 'open'. That is unless `open()` failed. | ||
| 2. If `open()` failed twice in the same sequence of calls, the final status will be 'closed', the first and last call receive an error, no events are emitted, and all callbacks will see that `status` is 'closed'. | ||
| _At the time of writing this is a new feature, subject to change, zero modules support it (including `levelup`)._ | ||
| ### `passiveOpen` (boolean) | ||
| Does db support `db.open({ passive: true })` which waits for but does not initiate opening? To the same but more comprehensive effect as : | ||
| ```js | ||
| if (db.status === 'opening') { | ||
| db.once('open', callback) | ||
| } else if (db.status === 'open') { | ||
| queueMicrotask(callback) | ||
| } else { | ||
| // Yield error | ||
| } | ||
| ``` | ||
| _At the time of writing this is a new feature, subject to change, zero modules support it._ | ||
| ### `openCallback` (boolean) | ||
| Does the db constructor take a callback? | ||
| ```js | ||
| var db = level(.., callback) | ||
| ``` | ||
| To the same effect as: | ||
| ```js | ||
| var db = level() | ||
| db.open(.., callback) | ||
| ``` | ||
| ### `createIfMissing`, `errorIfExists` (boolean) | ||
| Does `db.open(options, ..)` support these options? | ||
| Does `db.open()` support these options? | ||
@@ -292,8 +202,12 @@ <details> | ||
| | Module | Support | | ||
| | :---------- | :------ | | ||
| | `leveldown` | ✅ | | ||
| | `rocksdb` | ✅ | | ||
| | `memdown` | ❌ | | ||
| | `level-js` | ❌ | | ||
| | Module | Support | | ||
| | :-------------- | :------ | | ||
| | `classic-level` | ✅ | | ||
| | `rocks-level` | ✅ | | ||
| | `memory-level` | ❌ | | ||
| | `browser-level` | ❌ | | ||
| | `leveldown` | ✅ | | ||
| | `rocksdb` | ✅ | | ||
| | `memdown` | ❌ | | ||
| | `level-js` | ❌ | | ||
@@ -304,3 +218,3 @@ </details> | ||
| Do all db methods (that don't otherwise have a return value) support promises, in addition to callbacks? Such that, when a callback argument is omitted, a promise is returned: | ||
| Do all database methods (that don't otherwise have a return value) support promises, in addition to callbacks? Such that, when a callback argument is omitted, a promise is returned: | ||
@@ -315,19 +229,14 @@ ```js | ||
| | Module | Support | | ||
| | :------------------- | :------------------- | | ||
| | `abstract-leveldown` | ❌ (except iterators) | | ||
| | `leveldown` | ❌ (except iterators) | | ||
| | `rocksdb` | ❌ (except iterators) | | ||
| | `memdown` | ❌ (except iterators) | | ||
| | `level-js` | ❌ (except iterators) | | ||
| | `encoding-down` | ❌ (except iterators) | | ||
| | `deferred-leveldown` | ❌ (except iterators) | | ||
| | `levelup` | ✅ | | ||
| | `level-packager` | ✅ | | ||
| | `level` | ✅ | | ||
| | `level-mem` | ✅ | | ||
| | `level-rocksdb` | ✅ | | ||
| | `subleveldown` | ✅ | | ||
| | `multileveldown` | ✅ | | ||
| | `level-party` | ✅ | | ||
| | Module | Support | | ||
| | :---------------------------------- | :------------------- | | ||
| | `abstract-level` and dependents | ✅ | | ||
| | `abstract-leveldown` and dependents | ❌ (except iterators) | | ||
| | `levelup` | ✅ | | ||
| | `level-packager` | ✅ | | ||
| | `level` | ✅ | | ||
| | `level-mem` | ✅ | | ||
| | `level-rocksdb` | ✅ | | ||
| | `subleveldown` | ✅ | | ||
| | `multileveldown` | ✅ | | ||
| | `level-party` | ✅ | | ||
@@ -342,3 +251,3 @@ </details> | ||
| if (db.supports.events.put) { | ||
| db.on('put', () => { /* .. */}) | ||
| db.on('put', listener) | ||
| } | ||
@@ -349,3 +258,3 @@ ``` | ||
| Does db have the methods `createReadStream`, `createKeyStream` and `createValueStream`, following the API currently documented in `levelup`? | ||
| Does database have the methods `createReadStream`, `createKeyStream` and `createValueStream`, following the API documented in `levelup`? For `abstract-level` databases, a standalone module called [`level-read-stream`](https://github.com/Level/read-stream) is available. | ||
@@ -355,19 +264,14 @@ <details> | ||
| | Module | Support | | ||
| | :------------------- | :------ | | ||
| | `abstract-leveldown` | ❌ | | ||
| | `leveldown` | ❌ | | ||
| | `rocksdb` | ❌ | | ||
| | `memdown` | ❌ | | ||
| | `level-js` | ❌ | | ||
| | `encoding-down` | ❌ | | ||
| | `deferred-leveldown` | ❌ | | ||
| | `levelup` | ✅ | | ||
| | `level-packager` | ✅ | | ||
| | `level` | ✅ | | ||
| | `level-mem` | ✅ | | ||
| | `level-rocksdb` | ✅ | | ||
| | `subleveldown` | ✅ | | ||
| | `multileveldown` | ✅ | | ||
| | `level-party` | ✅ | | ||
| | Module | Support | | ||
| | :---------------------------------- | :------ | | ||
| | `abstract-level` and dependents | ❌ | | ||
| | `abstract-leveldown` and dependents | ❌ | | ||
| | `levelup` | ✅ | | ||
| | `level-packager` | ✅ | | ||
| | `level` | ✅ | | ||
| | `level-mem` | ✅ | | ||
| | `level-rocksdb` | ✅ | | ||
| | `subleveldown` | ✅ | | ||
| | `multileveldown` | ✅ | | ||
| | `level-party` | ✅ | | ||
@@ -381,8 +285,3 @@ </details> | ||
| ```js | ||
| { | ||
| encodings: { | ||
| utf8: true, | ||
| json: true | ||
| } | ||
| } | ||
| { utf8: true, json: true } | ||
| ``` | ||
@@ -393,29 +292,48 @@ | ||
| <details> | ||
| <summary>Support matrix</summary> | ||
| <summary>Support matrix (general support)</summary> | ||
| At the moment, this matrix just indicates general support of encodings, not that the listed modules support the `encodings` property exactly as described above. | ||
| _This matrix just indicates general support of encodings as a feature, not that the listed modules support the `encodings` property exactly as described above, which only works on `abstract-level` databases._ | ||
| | Module | Support | | ||
| | :------------------- | :------ | | ||
| | `abstract-leveldown` | ❌ | | ||
| | `leveldown` | ❌ | | ||
| | `rocksdb` | ❌ | | ||
| | `memdown` | ❌ | | ||
| | `level-js` | ❌ | | ||
| | `encoding-down` | ✅ | | ||
| | `deferred-leveldown` | ❌ | | ||
| | `levelup` | ✅ | | ||
| | `level-packager` | ✅ | | ||
| | `level` | ✅ | | ||
| | `level-mem` | ✅ | | ||
| | `level-rocksdb` | ✅ | | ||
| | `subleveldown` | ✅ | | ||
| | `multileveldown` | ✅ | | ||
| | `level-party` | ✅ | | ||
| | Module | Support | | ||
| | :------------------------------------- | :------ | | ||
| | `abstract-level` (and dependents) | ✅ | | ||
| | `abstract-leveldown` (and dependents) | ❌ | | ||
| | `encoding-down` | ✅ | | ||
| | `levelup` | ✅ | | ||
| | `level-packager` | ✅ | | ||
| | `level` | ✅ | | ||
| | `level-mem` | ✅ | | ||
| | `level-rocksdb` | ✅ | | ||
| | `subleveldown` | ✅ | | ||
| | `multileveldown` | ✅ | | ||
| | `level-party` | ✅ | | ||
| </details> | ||
| <details> | ||
| <summary>Support matrix (specific encodings)</summary> | ||
| _This matrix lists which encodings are supported as indicated by e.g. `db.supports.encodings.utf8`. Encodings that encode to another (like how `'json'` encodes to `'utf8'`) are excluded here, though they are present in `db.supports.encodings`._ | ||
| | Module | `'utf8'` | `'buffer'` | `'view'` | | ||
| | :-------------- | :------------ | :------------ | :------------ | | ||
| | `classic-level` | ✅ | ✅ | ✅ <sup>1<sup> | | ||
| | `memory-level` | ✅ <sup>2<sup> | ✅ <sup>2<sup> | ✅ <sup>2<sup> | | ||
| | `browser-level` | ✅ <sup>1<sup> | ✅ <sup>1<sup> | ✅ | | ||
| | `rocks-level` | ✅ | ✅ | ✅ <sup>1<sup> | | ||
| | `level@8` | ✅ <sup>3<sup> | ✅ <sup>3<sup> | ✅ <sup>3<sup> | | ||
| <small> | ||
| 1. Transcoded (which may have a performance impact). | ||
| 2. Can be controlled via `storeEncoding` option. | ||
| 3. Whether it's transcoded depends on environment (Node.js or browser). | ||
| </small> | ||
| </details> | ||
| ### `getMany` (boolean) | ||
| Does the db have a `getMany(keys[, options][, callback])` method, as documented in `abstract-leveldown`? | ||
| Does the database support `db.getMany()`? Always true since `abstract-level@1`. | ||
@@ -425,18 +343,19 @@ <details> | ||
| | Module | Support | | ||
| | :------------------- | :------------ | | ||
| | `abstract-leveldown` | ✅ 7.2.0 | | ||
| | `leveldown` | ✅ 6.1.0 | | ||
| | `rocksdb` | ❌ | | ||
| | `memdown` | ✅ | | ||
| | `level-js` | ✅ 6.1.0 | | ||
| | `encoding-down` | ✅ 7.1.0 | | ||
| | `deferred-leveldown` | ✅ 7.0.0 | | ||
| | `levelup` | ✅ 5.1.0 | | ||
| | `level` | ✅ 7.0.1 | | ||
| | `level-mem` | ✅ 6.0.1 | | ||
| | `level-rocksdb` | ❌ (`rocksdb`) | | ||
| | `subleveldown` | ✅ 6.0.0 | | ||
| | `multileveldown` | ✅ 5.0.0 | | ||
| | `level-party` | ✅ 5.1.0 | | ||
| | Module | Support | | ||
| | :------------------------------ | :------ | | ||
| | `abstract-level` and dependents | ✅ 1.0.0 | | ||
| | `abstract-leveldown` | ✅ 7.2.0 | | ||
| | `leveldown` | ✅ 6.1.0 | | ||
| | `rocksdb` | ✅ 5.2.0 | | ||
| | `memdown` | ✅ | | ||
| | `level-js` | ✅ 6.1.0 | | ||
| | `encoding-down` | ✅ 7.1.0 | | ||
| | `deferred-leveldown` | ✅ 7.0.0 | | ||
| | `levelup` | ✅ 5.1.0 | | ||
| | `level` | ✅ 7.0.1 | | ||
| | `level-mem` | ✅ 6.0.1 | | ||
| | `level-rocksdb` | ✅ 5.0.0 | | ||
| | `subleveldown` | ✅ 6.0.0 | | ||
| | `multileveldown` | ✅ 5.0.0 | | ||
| | `level-party` | ✅ 5.1.0 | | ||
@@ -447,3 +366,3 @@ </details> | ||
| Does the `db` have a `keys([options])` method that returns a key iterator? Also implies support of `iterator#mode`. | ||
| Does the database have a `keys([options])` method that returns a key iterator? Also implies support of `iterator#mode`. | ||
@@ -454,3 +373,3 @@ _At the time of writing this is a new feature, subject to change, zero modules support it._ | ||
| Does the `db` have a `values([options])` method that returns a key iterator? Also implies support of `iterator#mode`. | ||
| Does the database have a `values([options])` method that returns a key iterator? Also implies support of `iterator#mode`. | ||
@@ -473,3 +392,3 @@ _At the time of writing this is a new feature, subject to change, zero modules support it._ | ||
| In the form of: | ||
| Declares support of additional methods, that are not part of the `abstract-level` interface. In the form of: | ||
@@ -483,3 +402,3 @@ ```js | ||
| Which says the db has two methods, `foo` and `bar`, that are not part of the `abstract-leveldown` interface. It might be used like so: | ||
| Which says the db has two methods, `foo` and `bar`. It might be used like so: | ||
@@ -486,0 +405,0 @@ ```js |
@@ -17,3 +17,3 @@ 'use strict' | ||
| const manifest = supports({ | ||
| bufferKeys: value, | ||
| seek: value, | ||
| additionalMethods: { | ||
@@ -25,3 +25,3 @@ foo: value | ||
| shape(t, manifest) | ||
| t.is(manifest.bufferKeys, false) | ||
| t.is(manifest.seek, false) | ||
| }) | ||
@@ -50,3 +50,3 @@ | ||
| test('merges input objects without mutating them', function (t) { | ||
| const input1 = { bufferKeys: null, streams: false } | ||
| const input1 = { seek: null, streams: false } | ||
| const input2 = { streams: true, additionalMethods: {} } | ||
@@ -58,5 +58,5 @@ const manifest = supports(input1, input2) | ||
| t.same(input1, { bufferKeys: null, streams: false }) | ||
| t.same(input1, { seek: null, streams: false }) | ||
| t.same(input2, { streams: true, additionalMethods: {} }) | ||
| t.is(manifest.bufferKeys, false) | ||
| t.is(manifest.seek, false) | ||
| t.is(manifest.streams, true) | ||
@@ -63,0 +63,0 @@ shape(t, manifest) |
No alert changes
Improved metrics
- Total package byte prevSize
- increased by8.33%
30466
- Lines of code
- increased by64.04%
292
Worsened metrics
- Number of lines in readme file
- decreased by-16.46%
411
No dependency changes