Delete package-lock.json

[fenichelar]

Fixes #209. package-lock.json historically has not been included in fsevents. Including this file breaks this approach for releases.

[billyjanitsch]

Deleting package-lock.json does not address the issue you linked, and doesn't necessarily fix #209. package-lock.json is never published to npm and has no effect on dependency resolution at install time. Instead, it ensures that anyone developing the package has the same local dependency tree.

However, fsevents bundles its dependency on node-pre-gyp, which means that whichever version of node-pre-gpy happens to be installed on a developer's machine when they run npm publish gets published as part of the package. This essentially fixes the dependency to an exact version, despite the caret range in package.json. This does affect fsevents's install-time dependency tree, and happens regardless of whether a package-lock.json is present.

The difference is that with a package-lock.json, the version that exists on the publisher's machine (i.e. the one that gets bundled) is deterministic, which is a good thing: you know exactly which version will be bundled regardless of who runs npm publish and when. It would be very odd not to keep a package-lock.json if fsevents continues to bundle that dependency. But if you want to avoid fixing the dependency at install time entirely, the solution is not to delete package-lock.json but to stop bundling the dependency. (I'm not sure why it was bundled in the first place.)

[fenichelar]

@billyjanitsch I didn't do an exhaustive search, but it appears that strongloop does not include the package-lock.json file in any of the repositories I found on GitHub (not sure why). Did you see @es128 comments to this? Specifically, he said "Just do a fresh install". I think it is safe to assume they have no plans of pinning dependency versions... I understand how it works and I agree with you that this is a better option, but I don't think it is likely to be accepted.

[fenichelar]

Also, the package-lock file was added in the most recent commit. I think it was added by mistake.

[es128]

The lockfile did actually sneak in by mistake. I think it got pulled in when I used the npm version command.