When a lockfile exists with locked dependencies and all dependencies are removed from shard.yml, the next run of shards install/shards update does not update the lockfile which leads to incorrect information.
This test case describes this:
it "updated lockfile on completely removed dependencies" do
metadata = NamedTuple.new
lock = {web: "1.0.0"}
with_shard(metadata, lock) do
run "shards install" # or update ...
refute_installed "web"
refute_locked "web"
end
end
The reason is one condition for generate_lockfile? is packages not being empty. That just seems incorrect.
The question is, what should happen instead?
It seems the current assumption is that no dependencies means no shard.lock at all. I don't think that's a good idea because it can lead to running shards install all the time when a Makefile depends on shards.lock. IMO both shards install and shards update should always write shard.lock file (except for production mode). If there are no dependencies, shard.lock would just be empty. It still represents that dependency resolution has happened.
bundler also writes a Gemfile.lock with no dependencies.
When a lockfile exists with locked dependencies and all dependencies are removed from
shard.yml, the next run ofshards install/shards updatedoes not update the lockfile which leads to incorrect information.This test case describes this:
The reason is one condition for
generate_lockfile?is packages not being empty. That just seems incorrect.The question is, what should happen instead? It seems the current assumption is that no dependencies means no shard.lock at all. I don't think that's a good idea because it can lead to running
shards installall the time when aMakefiledepends onshards.lock. IMO bothshards installandshards updateshould always writeshard.lockfile (except for production mode). If there are no dependencies,shard.lockwould just be empty. It still represents that dependency resolution has happened. bundler also writes aGemfile.lockwith no dependencies.Related: #381