Does we need exclude yarn.lock and package-lock.json from all repository ?

[yoshinorin]

@hexojs/core

Currently some repositories not exclude yarn.lock & package-lock.json. Dependabot pull requests include yarn.lock like this.

https://github.com/hexojs/site/pull/815/files

Does we need add them to .gitignore before merge dependabot's pull request ?

[demurgos]

My opinion is that lockfiles should be commited for reproducibility (for all packages). And it's good that dependabot updates the lockfiles.

[JLHwung]

I also agree that lockfile should be commit to the repository as recommended from https://docs.npmjs.com/files/package-locks#using-locked-packages.

And we should stick to one package manager. After years on yarn vs npm I have no specific preference, both are good to go.

[yoshinorin]

Thanks!

I agree with your opnion & I prefer commit lockfiles. But, actually this repository setting exclude them. I wanna know hexo organization guideline.

[tomap]

I believe that yarn now relies on package-lock.json

[JLHwung]

I believe that yarn now relies on package-lock.json

@tomap What do you mean by yarn now relies on package-lock.json?

I wanna know hexo organization guideline.

@YoshinoriN Here is a historical talks around package lock files. At this time I think I can further convince @NoahDragon that with the help of renovate we can handle dependencies bumps more smoothly.

Package lock files are not published to npm. Even if it is published by improper configuration, the package manager would not respect package lock file in node_modules.

[yoshinorin]

@JLHwung Thanks.

Here is a historical talks around package lock files

I Got it.

I think I can further convince @NoahDragon

So, my understanding is that we need waiting @NoahDragon reply and discuss about this issue with him again. Is it correct?

[yoshinorin]

@demurgos @JLHwung @tomap Oops, I made mistake. Title were incorrect. Not yarn.lock vs package-lock.json but yarn.lock and package-lock.json

PS. Also, It's better if we can decide which use.

[tomap]

https://yarnpkg.com/blog/2018/06/04/yarn-import-package-lock/

Yarn can read package-lock But npm cannot read yarn.lock

So if we keep one, we should keep package-lock

Now, we have to decide if we start using package-lock or not.

For the sake of stability, we might want to use it, especially now that we have dependabot helping us for the updates.

Maybe, we should wait that we reduce the number of updates before we start using it

[tomap]

Hey, hexo build are failing. I don't want to jump to conclusions, but it might be caused by an npm update, which we cannot control without .lock file. Dependabot seem capable of handling that. Maybe we should start using those to avoid situation where we are unsure why the build broke

[tcrowe]

Can you give an example of where it's failing? I will go look through the logs.

[tomap]

https://travis-ci.org/hexojs/hexo/jobs/467045737

[yoshinorin]

@tomap @tcrowe The CI failed reason may not caused by lock file. I open #3392 about that.

[curbengh]

Though personally I'm not so keen on package-lock, I can live with it.

I suggest to include it as part of hexo@4, after all deps have been updated. Currently many deps are blocked by (depends on?) https://github.com/hexojs/hexo/pull/3598.

As part of this milestone?

[tomap]

1/ in general, I would not use yarn.lock, but package-lock json. yarn.lock is "deprecated in favor of the other

2/ In general, I would not use package-lock.json in any plugin. Each hexo user can decide or not to use a lock file on it's own repo, to have reproductible builds over time

3/ In some rare cases, temporarily, we could commit lock file to be able to fix known vulnerabilities using npm audit --fix, which I did, in some repos

4/ hexo-cli is a special case where it is not possible for the user to decide or not to use the lock file. In that case, it is possible that a dependency update breaks the package, and thus the ci of all hexo users. It occurred few months ago

5/ in any cases, the different cases should be advertized to inform user of the expected behavior

[ertrzyiks]

A lock file in library repo is more for developers than end users. Lock files of dependencies are ignored on installation anyway, the only relevant lock file is the one created in the root folder on the users' side. We can't even publish package-lock json file to npm registery.

According to 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

To protect maintainers from breaking change installed in their unprotected projects, I would keep package-lock.json in repositories. When I contribute to my repos once a month, I'm not going to spend the first hours with the old project hunting issues with broken devDependencies. I would rather spend that time productively on features/bugfixes.

For my personal projects, I moved to yarn because of npm's problems with version resolution I encountered twice, so I would even vote for `yarn.lock. But to have any lock file is better than nothing.

hexo-cli can be installed locally and pinned with lock file too. Then it can be used like yarn hexo [command] or some npm fallback, like "scripts".

I prefer the flow with lock file committed and dependency bot updating the versions so I can switch to new version deliberately with care, rather than risking broken development experience every time I run yarn or npm install in the newly cloned repo.

[stevenjoezhang]

I will close this issue because I believe the problem discussed has been resolved. In practice, many Hexo plugin repositories do not retain the package-lock.json, but it has been shown that we have hardly encountered issues due to inconsistent dependency package versions.