Support Date versioning semantics

[twiggy]

What's the feature?

Allow a developer to specify a Date (6/5/2018 12:35:00+00) vs a version number in package.json.

I think the use of a "date in time" vs versioning could simplify or eliminate the package lock system. This is predicated on if the NPM databases stores date information when packages where published and "simulate" an npm install as if it was done at the given timestamp.

When a developer says lodash : 1.2.3.4 I think they naturally expect lodash and all of its dependencies to be frozen to the day 1.2.3.4 was released. Lets say that was 6/5/2018. A package.json file with lodash : { date : '6/5/2018' } would fill very natural, tell people how old the package was, and all sub-dependencies could be calculated as the package publisher of lodash 1.2.3.4 expects.

What problem is the feature intended to solve?

Package locks complicate merge processes. Merge conflicts with package.json are resolved at merge time, but then developers or hooks have to reprocess the lock files which doesn't feel quite right and could up version in an unexpected or somewhat hidden way. There are some projects that solve this via git extensions, but it seems odd and doesn't always work.

How can the CLI team reproduce the problem?

To reproduce have developer A produce a package lock and developer B product a package lock for the same package.json and versions. But have them do it days apart. One of the sub dependencies for a package must have changed increasing its version for developer B, but not for developer A. Then have them merge the files. Developer A tested their stuff with certain sub dependency version, but B with others. Both A and B should really be testing with the exact same versions or at least ideally.

Is the absence of this feature blocking you or your team? If so, how?

It is blocking us from using package locks as we'd like to. We simply run our build in the morning before deployments and run tests to ensure that if a package has a non static sub-dependency with a new version it doesn't break our app.

Is this feature similar to an existing feature in another tool?

Not that I could find. Its dependent on if the database has the information needed to resolve by "dates in time". I think a 3rd party tool might be able to generate a package lock using the dates in a custom package.json type file, but it doesn't really solve the merge problem and IMHO it would be better to just have this "built-in".

Is this a feature you're prepared to implement, with support from the npm CLI team?

Perhaps, it honestly might be beyond my capabilities, but I would like to help in anyway that I can including testing or at the very least a proof of concept.

Thanks so much for the hard work on NPM, it has taken dependency management forward in all software.

[legodude17]

This would make a great RFC over at https://github.com/npm/rfcs!