Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(package-lock): add package lock #2641

Closed
wants to merge 1 commit into from
Closed

Conversation

JLHwung
Copy link
Collaborator

@JLHwung JLHwung commented Jul 8, 2017

Added package lock generated from npm 5.

We can discuss on whether to add package lock file. If we agree on the lockfile, I will add package-log to every hexo-* repository.

@coveralls
Copy link

coveralls commented Jul 8, 2017

Coverage Status

Coverage remained the same at 97.152% when pulling 068bbc2 on chore/add-package-lock into c450e9b on master.

@JLHwung JLHwung mentioned this pull request Jul 8, 2017
@JLHwung JLHwung requested a review from NoahDragon July 8, 2017 09:36
@NoahDragon
Copy link
Member

IMHO, the package lock should maintain by the user. We could keep all dependencies are compatible with Hexo, and assume they are following the semver standard.

@JLHwung
Copy link
Collaborator Author

JLHwung commented Jul 10, 2017

Hi NoahDragon, honestly I have different opinions on package lock. I would explain in the following.

CI guards our builds is working with the dependencies on every building datetime T, but our package user will definitely use our package in a datetime t > T. During this time gap a new semver version of our dependencies might be published but untested. If our release cycle is long, say monthly, this will leave user vulnerable to unexpected dependencies bump.

The dependencies of our package's dependencies is uncontrolled unless shrink-wrap is used, that is, even 1.2.3 is used in our dependencies specification, the dependency of this 1.2.3 package will be slightly different over time.

The core concept of package-lock is to make npm a pure function independent of time. Once the CI share exactly same dependencies tree with our user, then we can ship our tested packages with firm confidence.

As is noted, npm recommended use package-lock on VCS: https://docs.npmjs.com/files/package-locks#using-locked-packages

@NoahDragon
Copy link
Member

Because Hexo depends on many other packages that developed by us like hexo-fs and hexo-util, each time when releasing a dependency package the Hexo main repo has to update due to the lock file (also has to publish a new version on npm, otherwise installing via npm won't get the latest lock file). This just increases the maintenance difficulty.

Actually, you almost convinced me to merge this PR, but when I publish the new version of hexo-fs to npm, I realize that each time we fix a dependency, we have to publish two npm package (one for the dependency, one for updated lock file in Hexo main repo). This is good and meets the industry standard, however, I don't think it will fit in Hexo for now, as lack of maintainers.

This is just my own opinion, please feel free to discuss.

@JLHwung
Copy link
Collaborator Author

JLHwung commented Jul 15, 2017

OKay. If we are lack of maintainers and would not consider package lock, I suggest add package-lock.json to gitignore so that devs using npm5 would not be bothered by an untracked package-lock.

Also I would raise a PR to remove package-lock on hexo-fs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants