Add package-lock.json to allow project dependency audits and reproducible builds

[brylie]

This PR adds package-lock.json to the project, which is a conventional practice for reproducible builds. This was prompted by a security advisory raised in issue #496. Adding the package-lock.json allows the project dependencies to be audited with npm audit and automatically resolved the security vulnerability.

Closes #496

Changes:

• add package-lock.json
• add --harmony flag to node ... command to enable ES6 features (namely the spread operator)
• update the Docker image to circleci/python:3.6
• remove Python 3.6.5 build step
• install the serverless package in user scope, instead of globally

[brylie]

Hei, could someone help me determine why the tests are failing? I can't see the reason for the errors based on the changes I made here.

[AndrewFarley]

@brylie CircleCI stuff is pretty much abandonware at this point, we're all waiting for the Github Actions stuff to be completed over at #482 . This project has gotten a bit stagnant I think many/most of the supporters/contributors have gotten extremely busy with work and life and such. If you want to help out, that PR for Github Actions could use some review/love/support to push it to the finish line, then we can get a few more of these PRs that are laying around merged in.

[brylie]

OK, well the crux of this PR is to add package-lock.json to this project to fix issue #496. Would you recommend I open a new PR with just the package-lock.json changes and ignore the Circle CI failures?

[miketheman]

CI issues notwithstanding, I'm uncertain I understand what this actually solves.

The author is creating a project that installs this plugin as a development dependency - which is totally normal.
After trying to reproduce their issue, I was unable to, and commented as such.

When it comes to package management for a library/plugin - distinctly different from an application - I believe the common practice is to leave a package-lock.json out of git, as this leverages the package.json dependency operators to resolve any subdependencies, otherwsie we, as library maintainers, have to content with the potential conflicts when updating the package-lock.json files.

Furthermore, the existence of a package-lock.json has no impact to an installed depednecy, as it's not packages into the deployment.

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package.

• https://docs.npmjs.com/configuring-npm/package-lock-json.html

So the only purpose it might have is for library developers to share - and has little to no impact on end users installing the plugin as a dependency - so I'm 👎 for this change.

Unless there's something that I'm missing, in which case I'm happy to learn more!