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
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

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 🌴

I am totally lost at the beginning. I am try to follow readme to create ~/pelias.json. I failed on the first step.this is my step
$ git clone https://github.com/pelias/config.git
$ cd config
$ npm install pelias-config
then i get npm error as following:
npm ERR! code ENOSELF
npm ERR! Refusing to install package with name "pelias-config" under a package
npm ERR! also called "pelias-config". Did you name your project the same
npm ERR! as the dependency you're installing?
npm ERR!
npm ERR! For more information, see:
npm ERR! https://docs.npmjs.com/cli/install#limitations-of-npms-install-algorithm

npm ERR! A complete log of this run can be found in:
npm ERR! /home/hupo/.npm/_logs/2018-01-18T06_55_54_793Z-debug.log

anyone can tell me what to do?

Version 4.1.2 of tap-spec was just published.

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

tap-spec 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 🌴

I've seen users post their pelias.json file in comments and there are fields I've never heard of before, also some settings can be old an deprecated.

We could ship a 'lint tool' as part of this repo which would scan the users local pelias.json and alert the user of errors, warnings etc.

We could then advise users to run the linter periodically to ensure their config is up-to-date and valid.

I noticed that removing this line doesn't seem to affect the the tests or functionality of this module?

I'm not super familiar with Joi so I wasn't able to establish if it's safe to remove it?
There doesn't seem to be any Joi config in this module.

@orangejulius do you remember how this works?

See this: 5646ef6

Specifically the change that reads:

generate: generate.bind( null, true )

and from the README:

Note: by default the merge is shallow

Elasticsearch 5.x for example does not support the index_concurrency setting, so it would be nice to at least have the option to do a shallow merge. bind removes that option, so now, no matter what, the exported generate will always perform a deep merge.

This option has been something we've had enabled in Mapzen Search for quite some time, and feels pretty solid. Postalcodes are not that much data (3 million records), and many people like to search on them.

It might be reasonable to consider switching them on by default.

Resolve PELIAS_CONFIG env var before using the path.

Have we thought about using something like nconf for this? I really like being able to override config options from the command line or ENV vars when testing and whatnot. This is obviously very low priority, but was just curious. It also allows you to merge various config files, as we are doing here already.

it appears that newer versions use "1.x" instead of "1.7".

version number here needs to be changed and published.

    x TypeError: Invalid apiVersion "1.7", expected a function or one of master, 1.x, 1.3, 1.2, 1.1, 1.0, 0.90
    x TypeError: Invalid apiVersion "1.7", expected a function or one of master, 1.x, 1.3, 1.2, 1.1, 1.0, 0.90

I can't really find an easy solution to my scenario. I'm planning on using Pelias with an external Elastic Search instance provisioned by AWS, and pelias running from a docker instance. Normally this would be as easy as setting the hostname as a environment variable. But with current config the hostname is only defined in a json which doesn't leave many options out:

• pointing to a different .json file at run time: not useful on scenarios where you have ES being provisioned automatically by Cloudformation and you don't have the hostname upon deployment
• using add-host with a fixed name not friendly since requires an IP rather than an host name.
• only solution seems to be patching the json at run time replacing some "tag" string.

My proposed solution would be to have the configuration have a search sequence from .json first, and environment variables second, to allow this configuration in those scenarios. Any thoughts for or against ?

This setting seems to have been removed in pelias/api@0a95dd2 and no longer supported?

Is it possible to choose only one datasource? When I edit the pelias.json setting just the OSM importer it stills try to import data from the Who's on First.

So I have managed to get pelias working with es 5 by removing the following parameters:

index_concurrency and refresh_interval from settings.index
Everything but 'type': 'geo_point' from the centroid.js partial (this is in the schema repo)

Check it out if you will.

I set PELIAS_CONFIG in my .bashrc file so that pelias.json does not clutter up my home directory. However, I have to unset that variable in order for the tests to pass.

Currently any issues with the pelias.json file cause the config code to output a very unclear error message that looks like this:

throw new Error( 'failed to merge config from path:' + path );

It doesn't give any indication that the problem is with the config file's syntax and definitely doesn't provide hints at the part of the file that has the syntax issue. There are many ways to validate JSON, surely we can bring one in and use it to create friendly error messages.

Version 2.9.6 of jshint was just published.

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

jshint 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 🌴

Currently, our README here advises people to copy our full default.json file and use it as a starter pelias.json. This is not really good because it locks people into all the defaults, and forces them to start with a super long config.

While it would be a little more work, ideally we would have a "starter" pelias.json explicitly for people to copy/paste as their initial pelias.json. This would only have a general framework of the full config and only have parameters that we expect people to override (like paths, etc). This would ensure that as we change the defaults, they will be propagated to most user's configs automatically over time.

Version 13.5.0 of joi was just published.

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

joi is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

good idea considering the size of config in pelias.json file!
I think that can be simply refact

Code which consumes config has the responsibility of first checking properties exist in order to avoid crashes/errors.

Some script use lodash to do things like _.isEmpty(config.imports.openaddresses.files)

Other script are much more verbose which a lot of vanillajs ™️ if/else checks such as:

  // check pelias-config for a list of blacklist files to load
  const settings = config.generate();

  // config does not contain the relevant properties
  // return a no-op passthrough stream
  if( !settings.imports || !settings.imports.blacklist ){
    return through.obj();
  }

  // config does not contain a valid list of files
  // return a no-op passthrough stream
  const bl = settings.imports.blacklist;
  if( !Array.isArray( bl.files ) || bl.files.length === 0 ){
    return through.obj();
  }

What would be cool is if pelias/config offered an API which could be used to do checks similar to _.isEmpty and retrieve properties as per _.get.

It would probably be easiest to just include lodash in this repo so we don't have to reinvent the wheel.

It would then be nice to go through our repos and clean up the if/else checks and make them prettier.

It seems like https://github.com/pelias/transit is not supported out-of-the-box in Pelias due to the sources and layers listed in that repo not being part of our default api.targets.canonical_sources & api.targets.layers_by_source config.

cc/ @orangejulius