bcoin-org / bcfg

Config parser for bcoin

bcfg

Config parser (used for bcoin).

Usage

const Config = require('bcfg');

// Will consider ~/.my-module the prefix directory.
const config = new Config('my-module', {
  alias: {
    'n': 'network'
  }
});

// Inject some custom options first.
config.inject({
  some: 'user',
  options: 'here'
});

config.load({
  // Parse URL hash
  hash: true,
  // Parse querystring
  query: true,
  // Parse environment
  env: true,
  // Parse args
  argv: true
});

// Will parse ~/.my-module/my-config.conf (throws on FS error).
config.open('my-config.conf');

// These will cast types and throw on incorrect type.
console.log(config.str('username'));
console.log(config.str('password'));
console.log(config.uint('userid'));
console.log(config.float('percent'));
console.log(config.bool('initialize'));

Contribution and License Agreement

If you contribute code to this project, you are implicitly allowing your code to be distributed under the MIT license. You are also implicitly verifying that all code is your original work. </legalese>

License

• Copyright (c) 2017, Christopher Jeffrey (MIT License).

See LICENSE for more info.

bcfg's Issues

Single dash arguments (like the kind Bitcoin Core use) set as series of "true" flags.

This is just a documentation of user error, perhaps nothing to fix. But I want a reference posted in case someone else does this.

Consider you're working with Bitcoin Core and you accidentally try to start bcoin with:

$ bcoin -blocksonly

What happens is the following:

Strictly because of the single dash, blocksonly gets interpreted as a series of single-letter keys (b, l, o, c...) , and sets all the corresponding values to "true" (the STRING, not a boolean). In the case of the letter n an "alias" already exists, so the value of network is set to "true":

bcfg/lib/config.js

Lines 908 to 923 in 1216c77

	for (let j = 1; j < arg.length; j++) {
	let key = arg[j];
	if ((key < 'a' || key > 'z')
	&& (key < 'A' || key > 'Z')
	&& (key < '0' || key > '9')
	&& key !== '?') {
	throw new Error(`Invalid argument: -${key}.`);
	}
	const alias = this.alias[key];
	if (alias)
	key = alias;
	this.args[key] = 'true';

So:

{
  b: 'true',
  l: 'true',
  o: 'true',
  c: 'true',
  k: 'true',
  s: 'true',
  network: 'true',
  y: 'true'
}

As bcoin continues to process the configuration parameters, it will alert the user the network is invalid:

$ bcoin -blocksonly
/Users/matthewzipkin/Desktop/work/bcoin/node_modules/bsert/lib/assert.js:84
    throw new AssertionError({
    ^

AssertionError [ERR_ASSERTION]: Unknown network.
    at Function.create (/Users/matthewzipkin/Desktop/work/bcoin/lib/protocol/network.js:135:5)
    at Function.get (/Users/matthewzipkin/Desktop/work/bcoin/lib/protocol/network.js:181:22)
    at new Node (/Users/matthewzipkin/Desktop/work/bcoin/lib/node/node.js:49:28)
    at new FullNode (/Users/matthewzipkin/Desktop/work/bcoin/lib/node/fullnode.js:40:5)
    at Object.<anonymous> (/Users/matthewzipkin/Desktop/work/bcoin/bin/node:41:14)
    at Module._compile (internal/modules/cjs/loader.js:956:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:973:10)
    at Module.load (internal/modules/cjs/loader.js:812:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1025:10) {
  type: 'AssertionError',
  name: 'AssertionError [ERR_ASSERTION]',
  code: 'ERR_ASSERTION',
  generatedMessage: false,
  actual: undefined,
  expected: true,
  operator: '=='
}

Proposal for internal store and namespaces.

Bconfig updates

Table of Contents

• Bconfig updates
• Parsing
  • File
  • Env
  • Args
  • Injected options
  • Hashes and Query (browser)
• Getting
• Filtering

Bconfig updates

There are several issues that have accumulated, so I will try to sum up
desired behaviour for the bcfg.

• Use camelCase to represent namespaces internally. Currently it only
  lower cases everything.
• remove special configuration type: config, that just overrides
  whatever is passed to getFile. This will remove inconsistency with Config
  option and multiple files update (#3).
• Files, Env, Args, Hash and Query should translate to camelCase for
  internal representation(1).
• Options injected from javascript can pass camelCase to pass the
  options(1).
• Module names can use -(dash) to have multi word names.
  (e.g. log-network)
• filter will use dash separated (dash-case) prefix, instead
  of ignoring case.

Parsing

File

Format of the file does not change. The thing that changes is how we
process the results.
Example:

option-example: 123
optionexample: 111

Current behaviour wont differentiate between these two. It will be
optionexample internally. These will be two different options with new
behaviour: optionExample and optionexample.

Env

Similar problem:

  MODULE_OPTION_EXAMPLE=123
  MODULE_OPTIONEXAMPLE=111

will be: optionexample internally. New behaviour optionExample and
optionexample.

Args

Similar.

  --option-example=123 --optionexample=123

This will be: optionexample internally. New behaviour: optionExample and
optionexample.

Injected options

Injected options have the similar behaviour.

config.inject({
  optionExample: 123,
  optionexample: 111
});

New behaviour will leave them as is, separate. (options being the namespace)

Hashes and Query (browser)

  query: https://..something/something?exampleOption=123&exampleoption=111
  hash: https://..something/something#exampleOption=123&exampleoption=111

These will also generate two separate internal options.

Getting

Getting configurations will still be the same, but will query keys with new
behaviour.

  config.str('example-option');
  config.str('exampleoption');

Now these will query two different options: optionExample and optionexample.

Filtering

Filtering will now use case information as namespace.

  // Configuration with `optionExample` and `optionexample`.
  const nconfig = config.filter('option');
  
  // will only have `example` from the `optionExample`.
  

Accept proper form in the alias values

When you configure aliases, if the configuration you are using is multi word, it does not accept - in the middle.

For example, 'p': 'http-port' would not work for http-port alias instead you will need to use 'p': 'httpport'.
I believe it should accept proper form for the aliases.