esy-issues
esy-issues copied to clipboard
Changing dependency path doesn't invalidate node_modules
Repro: change "bs-platform": "esy-ocaml/bucklescript#esy"
to "bs-platform": "/path/to/local/bucklescript"
, then do esy install
while having an existing node_modules.
I think the current approach is that it creates the build cache key on the dependency's version number and package name. So if you bump the version number I suspect it will work, but I think we might want to hash on either the package contents, or the hash of mtimes on files within the package (which might be faster and sufficiently unique - as well as detecting when you modify a file).
BTW I'm not modifying the package's content (they're symlinked and I wouldn't touch them anyway). I'm switching from a remote git url to a local one. What you said applies if I keep the same path but changes some content. In this case, the path's changed.
Also, since we'll be finding little bugs/fixes in the build cache, maybe we should have an escape hatch called esy purge myPattern
, which will say:
> esy purge myPattern
There are (3) build caches for packages matching "myPattern":
---------------------------------------------------------------
myPattern-1.0.0
└─ ~/.esy/store/_build/myPattern-1.0.0-83b5bc03c594d2
myPattern-1.0.1
└─ ~/.esy/store/_build/myPattern-1.0.1-9877bc03c594d0
myPatternxyz-2.0.0
└─ ~/esy/store/_build/.....
And two other packages that depend on those cached builds:
dependsOnThatPackage-2.0.0
└─ ~/.esy/store/_build/blah
anotherThingThatDependsOnThem-4.0.0
└─ ~/.esy/store/_build/blah
╭───────────────────────────────────────────────────────────────╮
│ WARNING ┊ │
│ ♼ ┊ Would you like to purge the above packages? [Y/n]? │
│ WARNING ┊ │
╰───────────────────────────────────────────────────────────────╯
Answer: [Y/n]?