mirror of
https://github.com/pezkuwichain/phishing.git
synced 2026-10-20 18:56:29 +00:00
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>
36 lines
1.1 KiB
YAML
36 lines
1.1 KiB
YAML
name: PR
|
|
on: [pull_request]
|
|
|
|
permissions: {}
|
|
|
|
jobs:
|
|
pr:
|
|
# continue-on-error was inherited from upstream and meant these four steps
|
|
# could never turn a pull request red. Two of them were failing — build since
|
|
# 2026-09-13 and deno for far longer — and nobody saw it, because the job
|
|
# reported success either way. A check that cannot fail is not a check.
|
|
strategy:
|
|
matrix:
|
|
step: ['lint', 'test', 'build', 'deno']
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 30
|
|
permissions:
|
|
contents: read
|
|
env:
|
|
YARN_ENABLE_SCRIPTS: false
|
|
steps:
|
|
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
|
with:
|
|
persist-credentials: false
|
|
- uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
|
with:
|
|
node-version: 'lts/*'
|
|
- uses: denoland/setup-deno@22d081ff2d3a40755e97629de92e3bcbfa7cf2ed # v2.0.5
|
|
with:
|
|
deno-version: vx.x.x
|
|
- name: ${{ matrix.step }}
|
|
if: always()
|
|
run: |
|
|
yarn install --immutable
|
|
yarn ${{ matrix.step }}
|