Closed richsilv closed 4 years ago
Happy to submit a PR to fix this if you confirm that it's a valid issue and whether it requires a new flag.
have the same issue with our locally installed packages
our use case could be more common as we use it in a monorepo where we do not publish any of the packages to a registry
Greatly detailed report and reproducing steps, thank you @richsilv. I agree and confirm that by default local packages such as this should be ignored. The PR should be simple and small so if you'd like to submit it I'd gladly merge.
Thanks @kruczy for confirming also that this is a valuable fix for you too.
Thanks for releasing this very important tool! There's one small issue preventing us from adopting it:
Expected Behavior
If you add a package from the local filesystem (e.g.
yarn add path/to/my/package
), an entry is created inyarn.lock
corresponding to the package which has noresolved
field. I would expect this package to be ignored bylockfile-lint
(or at least to have a flag to ignore it), given that the code is already on the host machine, even when the user has specifically requested to validate protocol schemas (or whitelisted allowed schemes some other way).Current Behavior
Possible Solution
Skipping host validation for entries without a
resolved
field inValidateHost.js
would resolve this, but I'm not sure whether it's acceptable to do so other than behind a flag.Steps to Reproduce (for bugs)
https://github.com/richsilv/lockfile-lint-bug-example/tree/master
Context
We have a single, common shared library required by a variety of different services, and we find it simpler to copy this package into the local filesystem and install from there when building containers than via a private or self-hosted registry. I can't imagine we're the only people doing this (although I'd be interested to know if I was wrong!). For all other, registry-sourced packages, we would certainly want to validate the protocol.
Your Environment