# level-manifest

> describe a levelup plugin for remote access

Latest version **1.2.0** (published 2013-11-25) · MIT license · 0 weekly downloads

## Install

```sh
npm install level-manifest
pnpm add level-manifest
yarn add level-manifest
bun add level-manifest
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 1.2.0 |
| Published | 2013-11-25 |
| First published | 2013-04-12 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 1 |
| Known vulnerabilities | 0 (+1 in 1 direct dependencies) |
| Install scripts | no |
| GitHub stars | 16 |
| Author | Dominic Tarr |
| Maintainers | dominictarr |

## Links

- npm: https://www.npmjs.com/package/level-manifest
- Repository: https://github.com/dominictarr/level-manifest
- Issues: https://github.com/dominictarr/level-manifest/issues
- npm.io page: https://npm.io/package/level-manifest

## Dependencies (1)

- [deep-extend](https://npm.io/package/deep-extend.md) ~0.2.5

## Recent versions

- 1.2.0 (latest) — 2013-11-25
- 1.1.1 — 2013-04-15
- 1.1.0 — 2013-04-15
- 1.0.3 — 2013-04-12
- 1.0.2 — 2013-04-12
- 1.0.1 — 2013-04-12
- 1.0.0 — 2013-04-12

## README

# level-manifest

Describe the functions that multilevel should provide access to on the client.

[![Build Status](https://travis-ci.org/dominictarr/level-manifest.png?branch=master)](https://travis-ci.org/dominictarr/level-manifest)

## Example

Suppose you implement a levelup plugin that adds some cool new features to a
[sublevel](https://github.com/dominictarr/level-sublevel)

retrive a js object describing what methods a client protocol should be able
to access.
``` js
var manifest = require('level-manifest')

var m = manifest(db)
```

`manifest` build a tree of sublevels.

``` js
{
  methods:   {},
  sublevels: {
    foo: {
      methods: {},
      sublevels: {}
    }
  }
}
```

Plugins extending a sublevel should add a `methods` property that describes
any new methods that can be used by a remote client.

for example, the default methods are specified like this:

``` js
var methods = {
  createReadStream  : {type: 'readable'},
  readStream        : {type: 'readable'},
  createValueStream : {type: 'readable'},
  valueStream       : {type: 'readable'},
  createKeyStream   : {type: 'readable'},
  keyStream         : {type: 'readable'},
  createWriteStream : {type: 'writable'},
  writeStream       : {type: 'writable'},
  isOpen            : {type: 'sync'},
  isClosed          : {type: 'sync'},
  put               : {type: 'async'},
  get               : {type: 'async'},
  del               : {type: 'async'},
  batch             : {type: 'async'},
  approximateSize   : {type: 'async'}
}
```

`readable`, and `writable` mean readable or writable streams,
(use `duplex` for a stream that is both readable and writable.)

A client should also provide support for these types:
``` js
var other = {
  error        : {type: 'error', message: 'not-supported'},
  createStream : {type: 'duplex'},
  nested       : {type: 'object', methods: {get: {type: 'async'}}}
}
```
`error` is used when a method has been disabled.

## License

MIT

---
_Source: https://npm.io/package/level-manifest · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._