chore: upgrade pkgs & builds

.eslintignore

@@ -0,0 +1,4 @@
+tmp
+node_modules/
+.git
+/examples

.eslintrc.json

@@ -0,0 +1,28 @@
+{
+  "extends": "groupon/node8",
+  "overrides": [
+    {
+      "files": "*.mjs",
+      "parserOptions": {
+        "sourceType": "module"
+      },
+      "rules": {
+        "node/no-unsupported-features": [
+          "error",
+          {
+            "version": 8,
+            "ignores": [
+              "modules"
+            ]
+          }
+        ]
+      }
+    },
+    {
+      "files": "*.test.js",
+      "env": {
+        "mocha": true
+      }
+    }
+  ]
+}

.gitignore

@@ -2,3 +2,5 @@ node_modules/
 npm-debug.log
 /tmp
 /npm-debug.log
+/.nyc_output
+/target

.npmrc

@@ -1 +1,2 @@
+ignore-engines=true
 registry=https://registry.npmjs.org

.travis.yml

@@ -1,10 +1,12 @@
 language: node_js
 node_js:
-  - 10.14.1
+  - 8
+  - 10
+  - 12
 deploy:
   - provider: script
-    script: ./node_modules/.bin/nlm release
+    script: npx nlm release
     skip_cleanup: true
     'on':
       branch: master
-      node: 10.14.1
+      node: 12

CONTRIBUTING.md

@@ -1,3 +1,5 @@
+<!-- Generated by npm init @grpn -->
+
 # Contributing
 
 🎉🏅 Thanks for helping us improve this project! 🙏
@@ -6,6 +8,7 @@ This document outlines some of the practices we care about.
 If you have any questions or suggestions about the process,
 feel free to [open an issue](#reporting-issues)
 .
+
 ## How Can I Contribute?
 
 ### Reporting Issues
@@ -20,18 +23,22 @@ If you report a bug, please follow these guidelines:
 * Include instructions on how to reproduce the issue.
   The instructions should be as minimal as possible
   and answer the three big questions:
-  1. What are the exact steps you took? This includes the exact versions of node, npm, and any packages involved.
+  1. What are the exact steps you took? This includes the exact versions of
+      node, npm, and any packages involved.
   1. What result are you expecting?
   1. What is the actual result?
 
 ### Improving Documentation
 
-For small documentation changes, you can use [Github's editing feature](https://help.github.com/articles/editing-files-in-another-user-s-repository/).
+For small documentation changes, you can use [Github's editing feature][ghedit].
 The only thing to keep in mind is to prefix the commit message with "docs: ".
-The detault commit message generated by Github will lead to a failing CI build.
+The default commit message generated by Github will lead to a failing CI build.
+
+[ghedit]: https://help.github.com/articles/editing-files-in-another-user-s-repository/
 
 For larger updates to the documentation
-it might be better to follow the [instructions for contributing code below](#contributing-code).
+it might be better to follow the
+[instructions for contributing code below](#contributing-code).
 
 ### Contributing Code
 
@@ -42,43 +49,123 @@ only to discover that it conflicts with plans the maintainers might have.
 
 The general steps for creating a pull request are:
 
-1. Create a branch for your change.
-   Always start your branch from the latest `master`.
-   We often prefix the branch name with our initials, e.g. `jk-a-change`.
-1. Run `npm install` to install the dependencies.
-1. If you're fixing a bug, be sure to write a test *first*.
-   That way you can validate that the test actually catches the bug and doesn't pass.
-1. Make your changes to the code.
-   Remember to update the tests if you add new features or change behavior.
-1. Run the tests via `npm test`. This will also run style checks and other validations.
-   You might see errors about uncommitted files.
-   This is expected until you commit your changes.
-1. Once you're done, `git add .` and `git commit`.
-   Please follow the [commit message conventions](#commits--commit-messages) described below.
+1. Create a branch for your change.  Always start your branch from the latest
+    `master`.  We recommend using `git wf start some-feature-name` by using
+    [git workflow][gitwf].  Run `npm install` to install the dependencies.
+1. If you're fixing a bug, be sure to write a test *first*.  That way you can
+    validate that the test actually catches the bug and doesn't pass.
+1. Make your changes to the code.  Remember to update the tests if you add new
+    features or change behavior.
+1. Run the tests via `npm test`. This will also run style checks and other
+    validations.  You might see errors about uncommitted files.  This is
+    expected until you commit your changes.
+1. Once you're done, `git add .` and `git commit`.  Please follow the
+    [commit message conventions](#commits--commit-messages) described below.
 1. Push your branch to Github & create a PR.
 
+[gitwf]: https://github.com/groupon/git-workflow
+
 #### Code Style
 
-In addition to any linting rules the project might include,
-a few general rules of thumb:
+In addition to any linting rules the project might include, a few general rules
+of thumb:
 
 * Try to match the style of the rest of the code.
 * We prefer simple code that is easy to understand over terse, expressive code.
-* We try to structure projects by semantics instead of role.
-  E.g. we'd rather have a `tree.js` module that contains tree traversal-related helpers
-  than a `helpers.js` module.
-* Actually, if you create helpers you might want to put those into a separate package.
-  That way it's easier to reuse them.
+* We try to structure projects by semantics instead of role.  E.g. we'd rather
+    have a `tree.js` module that contains tree traversal-related helpers than
+    a `helpers.js` module.
+* Actually, if you create helpers you might want to put those into a separate
+    package. That way it's easier to reuse them.
+
+#### Commits & Commit Messages
+
+Please follow the [angular commit message conventions][angular-commits].  We
+use an automated tool for generating releases that depends on the conventions
+to determine the next version and the content of the changelog.  Commit messages
+that don't follow the conventions will cause `npm test` (and thus CI) to fail.
+
+The short summary - a commit message should look like this:
+
+```
+<type>: <subject>
 
-### Publishing changes
+<body>
 
-(Notes for internal team)
+<references>
 
-This multi-repository is managed with [lerna](https://github.com/lerna/lerna)
-2.x.
+<footer>
+```
 
-When a PR has been merged to master, we can publish new package(s), maintain tags, bump versions etc. by running:
+Everything but the first line is optional.  The empty lines between the
+different parts are required.
+
+* `<type>`: One of the following:
+  - **feat:** Introduces a new feature. This will cause the minor version to go
+      up.  If this commit adds a feature to this module's public API, it's a
+      `feat:`
+  - **fix:** A bug fix. Causes a patch version bump.  A new feature is not (by
+      itself) a fix.
+  - **docs:** Changes to the documentation. This will also cause an increase of
+      the patch version so that the changes show up in the npm registry.
+  - **style:** Syntax cleanup & lint rule fixes.  Note that often it's better to
+      just amend the previous commit if it introduced lint errors, and tools
+      like `prettier` should be taking care of most `style` issues.
+  - **refactor:** Changes to the code structure without fixing bugs or adding
+      features.  If the functionality is unchanged, but you're touching active
+      code in the package, it's a `refactor`.
+  - **perf:** Performance optimizations.
+  - **test:** Fixing existing tests or adding missing ones.
+      Just like with **style**, if you add tests to a feature you just
+      introduced in the previous commit, consider keeping the tests and the
+      feature in the same commit instead.
+  - **chore:** Changes to the project setup and tools, dependency bumps,
+      and package-building house-keeping.  `chore` is not a judgement on how you
+      feel about a given work.  Changes to actual code are **NEVER** `chore`
+      commits.  If you're fixing, refactoring, or adding a feature, that is
+      by definition a `fix`, `refactor`, or `feat`.  If you're upgrading some
+      dev dependency, fiddling with the package.json author field, etc., that's
+      a `chore` commit.
+* `<subject>`: A [good git commit message subject][limit50].
+  - Keep it brief. If possible the whole first line should have at most 50
+      characters.
+  - Use imperative mood. "Create" instead of "creates" or "created".
+  - No period (".") at the end.
+* `<body>`: Motivation for the change and any context required for understanding
+    the choices made.  Just like the subject, it should use imperative mood.
+* `<references>`: Any URLs relevant to the PR go here.  Use one line per URL and
+    prefix it with the kind of relationship, e.g. "Closes: " or "See: ".  If you
+    are referencing an issue in your commit body or PR description, never use
+    `#123` but the full URL to the issue or PR you are referencing.  That way
+    the reference is easy to resolve from the git history without having to
+    "guess" the correct link even if the commit got cherry-picked or merged
+    into a different project.
+* `<footer>`: This part only applies if your commit introduces a breaking
+    change.  It's important this is present, otherwise the major version will
+    not increase.  See below for an example.
+
+[angular-commits]: https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commit-message-format
+[limit50]: http://chris.beams.io/posts/git-commit/#limit-50
+
+##### Examples
+
+A feature that introduces a breaking change:
 
 ```
-$ ./node_modules/.bin/lerna publish
+feat: Support --yes CLI option
+
+For existing projects all prompts can be inferred automatically.
+Manual confirmation for each default provides no value in that case.
+
+Closes https://github.com/my/project/issues/123
+
+BREAKING CHANGE: This removes support for interactive password entry.
+Users will have to login beforehand.
 ```
+
+A simple bug fix:
+
+```
+fix: Handle multi-byte characters in search logic
+```
+

es5.js

@@ -61,6 +61,5 @@ module.exports = Object.assign({
 
     // Additional mistakes
     'node/no-unsupported-features': [2, { version: 4 }],
-
   }),
 });