I agree. I have a bunch of little modules published on npm, and for all of them, I have a yarn.lock (or package-lock.json) lockfile committed in the git repo, but also listed in .npmignore so it's not part of the package published on npm. I do this so that all of the test/dev dependencies stay pinned to guaranteed working/tested versions, and so that there's a record of which versions of (non-dev) dependencies the library is known to work with. Here's a bunch of painful problems that happen when you don't check in your lockfile:

* One of the most frustrating things in the world is checking out a git repo that's missing any lockfiles and then finding out that its build script or unit tests are broken with the current versions of the dependencies, so you're blocked on doing any work with the repo until you fix that. The extra frustrating thing is that people who previously checked out the repo (including the maintainer) won't run into this issue, so this issue will fall onto new contributors and be an obstacle to them specifically!

* The next worst thing is getting a report from a user that your library no longer works with the current versions of its dependencies, and you don't even know which dependency is the problem or know of a good version of the dependency it worked with.

Putting the lockfile in .gitignore opens you up to the two above issues, and then barely helps. Your CI system isn't going to re-run your tests when your dependencies or sub-dependencies get updates. You're going to have to set that up separately and then you could set that process up to ignore or update your lockfile so it's not a reason to git-ignore your lockfile.