# `package.digest_mismatch`

The files of an installed package in `packages/` have been changed, added or removed since it was installed.

Area 11, [External services](/docs/external-services.md); not declinable; the next step is usually the human's.

## Why Jadpo refuses it

An installed package is someone else's code, and it is read-only in your
app. `jadpo.lock` holds a digest of its files as they were installed, a
fingerprint that changes when any file does. The digest no longer
matches, so the code your app runs isn't the code that was installed and
checked.

Jadpo won't choose for you whether the changes stay. Throwing them away
may lose work, and keeping them means your app carries its own copy of
the package from now on.

## What it looks like



The app has `Postcodes.v2` installed in `packages/postcodes/v2/`. Its
line in the lock holds the digest of the files as they were installed,
and the files have changed since.

jadpo.lock:

```jadpo
// Generated by Jadpo from the installed packages; update it with `jadpo package add`, `update` or `remove`, never by hand.
record lock 1

package Postcodes.v2 version 2.1.0 path ../postcodes digest sha256:0000000000000000000000000000000000000000000000000000000000000000
```

```text
error: Package `Postcodes.v2` differs from what was installed
 --> packages/postcodes/v2/package.jadpo
  reason: An installed package is read-only: `jadpo.lock` locks it with digest `sha256:0000000000000000000000000000000000000000000000000000000000000000`, and its files now give `sha256:fc196456d53ad674b39fbab39eca4883d512f52feb90d687d22c2eeb2c9721e7`, so a file in `packages/postcodes/v2/` was changed, added or removed since it was installed.
  next: Restore `packages/postcodes/v2/` from version control, or install it again from its source with `jadpo package update postcodes`; change the app's own code instead (human)
  rule: package.digest_mismatch
  help: https://jadpo.dev/docs/errors/package.digest_mismatch

check failed: 1 error, 2 files
```

`(human)` at the end of the `next:` line tells your coding agent to stop
and ask you which fix you want, because the choice is yours to make: it
decides whether the changes to the package's files are kept.

## How to fix it

The question is whether the changes to the package should stay.

**If they shouldn't**, restore the folder from version control:

```sh
git restore packages/postcodes/v2/
```

The package is as it was installed again, and its digest matches the lock.
Anything the change was for belongs in the app's own code, which may call
the package.

**If the changes are already committed, or you want its newest
release**, install it again from its source:

```sh
jadpo package update postcodes
```

`update` replaces the folder with the release its source has: the
newest one, or the one the lock names when there is none newer. When the
release is newer, it shows what changed in the package's surface for
review. The lock holds the installed release's digest.

**If the app is to keep its own changed copy**, move it to where the
app's own integrations live, change each `use packages/postcodes` to
`use shared/providers/postcodes`, and remove the installed package:

```sh
mkdir -p shared/providers/postcodes
cp -R packages/postcodes/v2 shared/providers/postcodes/
jadpo package remove postcodes
```

`Postcodes.v2` is now the app's own code, and your app may change it.
It is no longer updated from its source, and the lock no longer lists it.

## Related

- [Where packages live](/docs/where-packages-live.md)
- [Installing safely](/docs/where-packages-come-from.md#installing-safely)
- [How packages are installed and linked](/docs/how-packages-are-installed-and-linked.md)