I'm currently exploring the idea of making the codec typing a little more strict, but need some clarification.

From what I can see; a codec encoder looks like this:

  type CodecEncoder<I> = CodecStringEncoder<I> | CodecBufferEncoder<I>

  interface CodecStringEncoder<I> {
    encode: (val: I) => string;
    decode: (val: string) => I;
    buffer: false;
    type: string
  }

  interface CodecBufferEncoder<I> {
    encode: (val: I) => Buffer;
    decode: (val: Buffer) => I;
    buffer: true;
    type: string
  }

such that:

• if buffer === false then it is expected that the encoder will

  • encode to a string
  • decode from a string

• if buffer === true then it is expected that the encoder will

  • encode to a Buffer
  • decode from a Buffer

Is this correct?

cc: @vweevers

there was lots of stuff that used that, so updating to latest level breaks all that stuff.

should be like this:
https://github.com/Level/levelup/blob/4c81da838f5b435b498e45b59025c3da463f8d10/lib/codec.js#L14-L18

but it's like this:

https://github.com/Level/codec/blob/master/index.js#L22-L26

console.log(encode(1000000000)>encode(100000000));
echo false

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

We can revert #12 after Level/encoding-down#18.

When you use the json encoding and store a buffer you get back an object like {type: 'Buffer': data: [...]}. It would be nice to augment the JSON.parse with buffer handling. Is this something that you would all be interested in accepting a PR for?

"Encoding logic for levelup" is outdated. Update:

• GH description
• package.json
• README.md

• Add node badge
• Fix api style
• Remove Publishers section (I added it but doesn't really mean much)
• Fix copyright year
• levelup -> level-codec

This module currently has 2 apis, which differ in the way encodings are inherited. Those two snippets are equivalent:

value = encodeValue(value, [{ valueEncoding: 'hex' }, db.options]);

var codec = new Codec(db.options);
value = codec.encodeValue(value, { valueEncoding: 'hex' })

The first is more generic as it supports inheritance over n encoding options, whereas the second one works exactly with what we need in levelup.

We could change the class api to take n encoding options too:

var codec = new Codec([optionsA, optionsB]);
value = codec.encodeValue(value, [optionsC, optionsD]);

I guess the real question is: Do we want to make this module truly generic, or tie it to it's main use cases: levelup and multilevel.

Input from people having to use levelup's codec logic would help a lot.

@ralphtheninja @dominictarr @substack

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organiszation’s settings page, under Installed GitHub Apps.

cc @MeirionHughes

new Buffer(... is depreciated in node 10. So far I've only seen the use in this repo.

https://github.com/Level/codec/blob/master/lib/encodings.js#L23
https://github.com/Level/codec/blob/master/lib/encodings.js#L54

the new approach is to use Buffer.alloc(... or Buffer.from(...

Looks like its been deprecated since Node 6. But its only in Node 10 that node seems to start warning about it - I suspect they may drop it in Node 12.

The devDependency tape was updated from 4.9.2 to 4.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

so we don't need this in levelup: https://github.com/rvagg/node-levelup/blob/master/lib/levelup.js#L354-L365

Major for dropping node 9.

So, given the current state we have the following results:

I want to write a test that covers the following line

So I add the following test:

  t.test('no keys and no values not decoding', function (t) {
    var decoder = codec.createStreamDecoder({})
    t.equal(decoder(null, Buffer.from('hey')), undefined)
    t.equal(decoder(Buffer.from('hey')), undefined)
    t.end()
  })

The test works (passes) and covers the line correctly. However, for some reason nyc reports new lines in the code that aren't covered, which seems a bit weird to me. How can adding an extra test remove coverage? At worst it it's a bad test that doesn't add coverage, but it should never remove coverage imo. See below:

What's going on here?