Commit package-lock.json

[levino]

You are running a postinstall script to bootstrap the lerna multirepo. That is nice. But you do not commit the package-lock.json. That is good practice and should be done. Will save you lots of headaches with "works on my machine" issues. From the lerna bootstrap logs:

lerna success Bootstrapped 20 packages
npm notice created a lockfile as package-lock.json. You should commit this file.
added 948 packages in 72.476s

[levino]

If you are concerned about the huge diff you always have with the lockfiles, that is not a problem: They do not matter. Just accept all changes to it.

[pubkey]

I do not think a library should add the package-lock.json. See this discussion.
To prevent the works on my machine-problem, you should add the package-lock to your project, not a single dependency.

[levino]

The lockfile should never be published to NPM. It should however be part of the version controlled source code. It is actually even impossible. https://docs.npmjs.com/files/package-lock.json

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.

Anyhow. There are a bunch of lockfiles in the packages themselves, but none for the web3 package and the project as a whole, which does not make sense.

Keep in mind: Anyone who installs the published package will always install the latest versions of any dependency.

IMO the lockfile should be commited at the toplevel, all other lockfiles should be removed. The lockfile can also be occasionally be removed and recreated in order to always use the latest patches. Deleting a lockfile and having it recreated with npm install should not break anything if the dependencies are correctly maintained.

[pubkey]

Didn't know that. My comment is invalid then.

[levino]

Maybe another way to see it is: A lockfile makes sure that every developer of a project uses the exact same versions of the dependencies for her local dev setup. Nothing more.

[gburtini]

100% agreed. This is too important of a project to be subject to dependency changes. Lockfiles should always be committed.