Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bump version to
0.10.2
and update changelog.I also properly shrinkwrapped the package tonpm-shrinkwrap.json
, so that's a lot smaller and a lot more reasonable now.I completely removed
npm-shrinkwrap.json
, because it doesn't allow Travis CI to installdevDependencies
that are necessary to run tests. Then I did some searching around and found this blog that walks throughpackage.json
,package-lock.json
, andnpm-shrinkwrap.json
. It's not entirely clear from that blog whether or not we should be usingpackage-lock.json
ornpm-shrinkwrap.json
, because he doesn't explicitly cover what would be appropriate when publishing a plugin type of package on NPM.However, I googled "hubot plugin npm-shrinkwrap.json" and the only search result was...this very repository. Starting to suspect we had been doing the wrong thing, I searched for "hubot plugin package-lock.json" and got a lot more search results:
And most tellingly, none of those plugins had
npm-shrinkwrap.json
files!Due to that, this PR:
npm-shrinkwrap.json
file.gitignore
package-lock.json
fileI also figured out that the
package-lock.json
file savesdev: true
for alldevDependencies
, so we should be able to ignore those dependencies when updating this in st2chatops, and also when generating that project's package lock file. If anybody knows any JS and/or NPM gurus that can double check this decision, please contact them.I also double checked that our CI builds all actually did pass all of the tests for the node versions that we care about, since they "passed" but should have failed in #200. There's a failure with Node v12, but we don't support that yet so it's not a big deal. We do test it though, and include it as an allowed failure.