Check in a dependency lock file

[kmannislands]

It's npm's faster, safer cousin.

Lockfiles bring nice predictability in dependencies across multiple node versions as well.

It is basically a drop in replacement for npm as far as devs are concerned.

Edited: npm is prefered over yarn, so the task here is to generate a package-lock.json and check it in.

[alecgibson]

As I mentioned on the PR, npm v5 has a package-lock.json file that we can use instead of adding another dependency.

[curran]

I vote to close this issue. Users that consume sharedb can use Yarn.

[kmannislands]

@curran consumers can use whatever package manager they want, of course.

The idea with this ticket is really to check in a dependency lockfile for developmer sanity. Seems npm is favored around here over yarn, which is fine. I went and updated the title of the ticket to clarify.

I was thinking of generating and checking in a package-lock.json and .gitignore'ing yarn.lock.

[curran]

I see what you mean. Well, adding package-lock.json would be trivial! Maybe submit a PR?

As I understand, package-lock.json would only impact folks working with the ShareDB codebase itself, but not consumers of the package. Is that right? Only ShareDB developers (not users) would benefit from this?

https://docs.npmjs.com/files/package-lock.json#description

[alecgibson]

Please go ahead and raise a PR to check in package-lock.json. In terms of preferring npm; my own thinking for this is:

• it's one less dependency to worry about
• the Travis build uses npm, and therefore anyone else using npm (especially with a package-lock.json) should reasonably expect the project to build and tests to pass; any other package manager may work, but won't be guaranteed by a green build

[curran]

The Travis use case is great motivation for this change.

[curran]

Suggesting to close this, as the PR that solves it has not been merged (and it's been around 5 months).

It doesn't really feel like that big a win anyway.