Add lock files

[demurgos]

This commit adds lock files to Vinyl. They are especially important for Vinyl since you are still supporting Node versions that reached EOL while multiple packages already dropped support for these versions. They do not affect consumers but help developers and CI to get reproducible builds and spot errors caused by transitive dependencies.

[phated]

They do not affect consumers

This is the problem with lockfiles - your CI might be passing yet a transitive dependency could have broken you and you won't know until a consumer encounters the error.

[demurgos]

They solve a different issue: reproducible builds. To keep dependencies up-to-date, there are tools such as Greekeeper that may help with spotting errors with dependencies before consumers do.

But I see your point, so as you wish.

[demurgos]

After thinking about it you are right: applications should commit it but it's a bad idea for libraries.

[demurgos]

Do you have any comments regarding this Yarn blog post recommending lock files for libraries?

Their main point is that user will always report issues faster than any CI and that lock files still bring benefits regarding dev dependencies.

[phated]

I disagree with that point because many of the gulp projects (including this one) were worked on in isolation before being promoted to being used in gulpjs/gulp#4.0 branch. I don't take much heed in yarn/babel/react dev patterns because they all forwent the multi-repo approach of the node ecosystem in favor of their mono-repo. And I don't take much heed in npm because they kicked out their project lead and caved to the yarn pressure. I think the way I've done gulp 4 is still the right way to develop for the node community (though there needs to be some tooling created to streamline some aspects).

[demurgos]

Thanks for the reply. Regardng the mono/multi approach and npm direction, I definitely agree. I don't know if this is what you had in mind, but I still consider Gulp's plugin system as one of the best compared to others such as Grunt, Webpack or Hexo, and I use it as an example.

I see what you mean regarding the projects being developed in isolation, but I guess that they could be still considered in "beta" until Gulp 4 gets released: they should start to be more used soon.

Overall, this issue at least helped me have a better understanding of the various arguments for/against lock files. I think I'll try different approaches and compare how it works for me: with and without lock files. I'd also like to check if there is some value to commit the lock files on my machine for reproducibility but configure CI to ignore it by default: it would keep the benefit of CI pulling the latest version while tracking the history of tested dependency trees in case of issue.