@pezkuwi/util, util-crypto and x-fetch now require ^14.0.26, which brings
@pezkuwi/wasm-crypto 7.5.20 in place of 7.5.17. The lockfile moves with it.
axios moves to ^1.20.0 in resolutions, with the lockfile entries that the
Dependabot PR for it (#11) left out; without them `yarn install --immutable`
refused to run and every check on that PR failed.
Lock Threads has failed on every scheduled run: lock-threads v4 rejects a
github-token longer than 100 characters, and GitHub's tokens now are. v6.0.2
fixes the validation. Since v5 the action also locks discussions by default;
process-only keeps it to issues and pull requests, as before and as the job's
permissions allow.
The build rewrites every @pezkuwi import into a deno.land URL, so @pezkuwi/util
becomes https://deno.land/x/pezkuwi/util/mod.ts. Upstream can do that because
deno.land/x/polkadot is published. Our fork renamed the prefix to x/pezkuwi and
never published there: deno.land/x/pezkuwi answers 404, and `deno check` has
failed on three modules ever since. Reproduced locally with the same Deno the
workflow installs, 2.9.7:
TS2307 Cannot find module 'https://deno.land/x/pezkuwi/util/mod.ts'
TS2307 Cannot find module 'https://deno.land/x/pezkuwi/util-crypto/mod.ts'
TS2307 Cannot find module 'https://deno.land/x/pezkuwi/x-fetch/mod.ts'
import_map.in.json is the tooling's own hook for exactly this —
pezkuwi-dev-deno-map merges its entries into the generated import_map.json. All
three are mapped to npm: specifiers, which Deno resolves natively, at the same
version ranges the node build uses. The three packages are already on npm, so
nothing new is published and the Deno build now checks against the very code we
ship. `yarn deno` exits 0.
This deliberately does not decide whether we ever claim deno.land/x/pezkuwi. If
we do, the mappings come out again; until then the build works with what we have.
The reason none of this was noticed is the second half of the change. The PR job
carried continue-on-error from upstream, so its four steps could never turn a
pull request red: build had been failing since 2026-09-13 and deno for far
longer, and the job reported success throughout. All four pass now — verified
locally, lint included, on a clean tree — so the flag is gone and they are gates
again.
deno.lock joins mod.ts and import_map.json in .gitignore: same check, same kind
of generated artifact. package.json carries the key order its own build:before
step produces.
Gate: scripts/checkDenoMap.mjs, in the Lists workflow so it runs even when the
toolchain cannot be installed. Nails: removing the map, bumping a dependency
without the map, adding a @pezkuwi dependency with no mapping, and leaving a
mapping behind after its dependency goes — each turns it red.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Say where this repository actually is
On 2026-04-21 a commit pointed repository, homepage and bugs at our Gitea
instance — "migrate git dependencies to Gitea mirror". Nothing else moved.
origin is still GitHub, the published @pezkuwi/phishing still says GitHub, and
git.pezkuwichain.io/pezkuwichain/phishing answers 500, so everyone who installs
the package has been given a dead homepage and a dead bug tracker.
It also broke the Master build on 2026-09-13, when the toolchain began reading
the field. @pezkuwi/dev, which is ours, does this:
const repoPath = pkg.repository.url
.split('https://github.com/')[1]
.split('.git')[0];
A URL from any other host makes [1] undefined and the build dies with "Cannot
read properties of undefined (reading 'split')" — a message that names neither
the field nor the file. Three runs failed that way and master has had no green
build since.
The metadata now says what is true today. This is not a decision about where
the project should live: it is an alignment with where the code already is and
with what we already publish.
That migration is still worth finishing, and this is the sequencing it needs.
Moving the repository to Gitea for real means fixing @pezkuwi/dev first, so a
toolchain built for a state that hosts its own git stops assuming github.com.
scripts/checkRepoMeta.mjs is the tripwire: it fails the metadata here rather
than letting it surface as an unreadable stack trace or ship as a dead link.
The check runs in the Lists workflow, which has no toolchain to install and so
still runs when the build does not. Nails: restoring the April commit turns
three cases red, migrating only half the repository turns two red, and leaving
homepage behind on the old host turns one red.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Hold the new check to the repository's own lint rules
The file I added failed all seven of them and lint had been green: the licence
header every file here carries, import order, an optional chain, object keys in
ascending order and an argument on its own line. Verified with eslint run the
way CI runs it, without --fix.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Update phishing URL to phishing.pezkuwichain.io
- Update author to Dijital Kurdistan Tech Inst
- Update README with Pezkuwi project references
- Update IPFS reference to pezkuwichain.io
- Rebrand all package references from @polkadot to @pezkuwi
