Spent this morning getting templates/evm-midnight-v2 running on v-next and hit five things in a row. All of them reproduce from a clean clone with the template's own Dockerfile, so I don't think it's my machine. I have working fixes for all five and I'm happy to open a PR if you want it in this shape.
Environment: Docker on Windows, template Dockerfile unmodified to start, docker build -t evm-midnight -f Dockerfile ..
1. The pinned Compact compiler no longer exists
packages/contracts-midnight/contract-round-value/package.json compiles with +0.33.0-rc.2, but the Dockerfile only installs 0.31.0, so bun run build:midnight dies:
Couldn't find compiler for x86_64-unknown-linux-musl (0.33.0-rc.2)
Directory does not exist: "/root/.compact/versions/0.33.0-rc.2/x86_64-unknown-linux-musl"
Adding compact update 0.33.0-rc.2 doesn't save you, because that release is gone:
Error: Failed to update
Caused by: Couldn't find version 0.33.0-rc.2
compact list today offers 0.34.0, 0.31.1, 0.31.0, 0.30.0, 0.29.0, 0.28.0, 0.26.0, 0.25.0, 0.24.0, 0.23.0, 0.22.0. No 0.32.x, no 0.33.x. So the template is pinned to something nobody can install any more.
2. Moving to 0.34.0 then trips the runtime pin
Repinning to +0.34.0 compiles, and the deploy fails instead:
CompactError: Version mismatch: compiled code expects 0.19.0, runtime is 0.18.0-rc.1
checkRuntimeVersion wants an exact minor match while major is 0, so a newer runtime doesn't satisfy an older compiler either. 0.34.0 emits for @midnight-ntwrk/compact-runtime 0.19.0; the template pins 0.18.0-rc.1 in packages/contracts-midnight, packages/frontend and packages/tests.
Bumping those three to 0.19.0 works and is low risk: the dependency sets of 0.18.0-rc.1 and 0.19.0 are identical, both on @midnightntwrk/onchain-runtime-v4 ^4.0.0-rc.3.
There's a choice here that's yours, not mine. Either pin the pair (0.34.0 + 0.19.0), or republish 0.33.0-rc.2 and keep 0.18.0-rc.1. Pinning the released pair seems better for anyone cloning cold.
3. graphql 17 breaks the batcher and the Midnight deploy
Nothing pins graphql, so a caret range pulls 17.0.2, which has been npm latest since 15 June. It's ESM only. graphql-tag@2.12.7 still requires it, and Bun refuses:
TypeError: require() async module ".../graphql@17.0.2/node_modules/graphql/index.mjs" is unsupported. use "await import()" instead.
at .../graphql-tag/lib/graphql-tag.umd.js:2:76
This one hits the batcher and the Midnight contract deploy, and it's the first thing anyone cloning today will see. Fix that worked:
"overrides": { "graphql": "16.14.2" }in the template's root package.json.
4. The proof-server binary won't spawn on Debian
@effectstream/npm-midnight-proof-server@0.200.1 downloads midnight-proof-server-linux-amd64-9.0.0-rc.5.zip fine, then:
ENOENT: no such file or directory, posix_spawn '.../proof-server/midnight-proof-server'
The file is right there, 28MB, executable. The binary is Nix built and its ELF interpreter is hardcoded:
$ ldd midnight-proof-server
/nix/store/jms7zxzm7w1whczwny5m3gkgdjghmi2r-glibc-2.42-51/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
That store path doesn't exist on the Debian base image, and a missing interpreter reports as ENOENT on the binary itself, which sends you looking in the wrong place for a while. Two fixes, both work:
RUN mkdir -p /nix/store/jms7zxzm7w1whczwny5m3gkgdjghmi2r-glibc-2.42-51/lib \
&& ln -sf /lib64/ld-linux-x86-64.so.2 \
/nix/store/jms7zxzm7w1whczwny5m3gkgdjghmi2r-glibc-2.42-51/lib/ld-linux-x86-64.so.2or patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 on the downloaded binary, which survives the store hash changing next time the binary is rebuilt. Debian's glibc 2.41 runs the 2.42 built binary without complaint.
Worth noting the wrapper has a --docker path too, which isn't much use when you're already inside a container.
5. Frontend build OOMs on a 6GB Docker VM
bunx vite build transforms about 8,962 modules and dies at exit 134, node::OOMErrorHandler. Node's default heap inside a 5.8GB VM isn't enough. Scoping the flag to the one script fixes it:
"build": "NODE_OPTIONS=--max-old-space-size=4096 bunx vite build --mode dev"
Setting NODE_OPTIONS on the container instead is a trap: it changes Bun's module loading and brings the graphql error in item 3 back in processes that were otherwise fine.
After all five
Full stack comes up green: local Midnight node producing blocks, indexer, proof server on :6300/health, both Hardhat chains with contracts deployed, Compact contract compiled and deployed, sync node answering :9999/api/erc721, batcher, frontend on :10599.
The local Midnight node plus proof server is the reason I went with this template over rolling my own, so getting it to a clean-clone build seems worth doing. Say the word and I'll send the PR.
Spent this morning getting
templates/evm-midnight-v2running onv-nextand hit five things in a row. All of them reproduce from a clean clone with the template's own Dockerfile, so I don't think it's my machine. I have working fixes for all five and I'm happy to open a PR if you want it in this shape.Environment: Docker on Windows, template Dockerfile unmodified to start,
docker build -t evm-midnight -f Dockerfile ..1. The pinned Compact compiler no longer exists
packages/contracts-midnight/contract-round-value/package.jsoncompiles with+0.33.0-rc.2, but the Dockerfile only installs0.31.0, sobun run build:midnightdies:Adding
compact update 0.33.0-rc.2doesn't save you, because that release is gone:compact listtoday offers 0.34.0, 0.31.1, 0.31.0, 0.30.0, 0.29.0, 0.28.0, 0.26.0, 0.25.0, 0.24.0, 0.23.0, 0.22.0. No 0.32.x, no 0.33.x. So the template is pinned to something nobody can install any more.2. Moving to 0.34.0 then trips the runtime pin
Repinning to
+0.34.0compiles, and the deploy fails instead:checkRuntimeVersionwants an exact minor match while major is 0, so a newer runtime doesn't satisfy an older compiler either. 0.34.0 emits for@midnight-ntwrk/compact-runtime0.19.0; the template pins0.18.0-rc.1inpackages/contracts-midnight,packages/frontendandpackages/tests.Bumping those three to
0.19.0works and is low risk: the dependency sets of 0.18.0-rc.1 and 0.19.0 are identical, both on@midnightntwrk/onchain-runtime-v4 ^4.0.0-rc.3.There's a choice here that's yours, not mine. Either pin the pair (0.34.0 + 0.19.0), or republish 0.33.0-rc.2 and keep 0.18.0-rc.1. Pinning the released pair seems better for anyone cloning cold.
3. graphql 17 breaks the batcher and the Midnight deploy
Nothing pins graphql, so a caret range pulls 17.0.2, which has been npm
latestsince 15 June. It's ESM only.graphql-tag@2.12.7still requires it, and Bun refuses:This one hits the batcher and the Midnight contract deploy, and it's the first thing anyone cloning today will see. Fix that worked:
in the template's root
package.json.4. The proof-server binary won't spawn on Debian
@effectstream/npm-midnight-proof-server@0.200.1downloadsmidnight-proof-server-linux-amd64-9.0.0-rc.5.zipfine, then:The file is right there, 28MB, executable. The binary is Nix built and its ELF interpreter is hardcoded:
That store path doesn't exist on the Debian base image, and a missing interpreter reports as ENOENT on the binary itself, which sends you looking in the wrong place for a while. Two fixes, both work:
RUN mkdir -p /nix/store/jms7zxzm7w1whczwny5m3gkgdjghmi2r-glibc-2.42-51/lib \ && ln -sf /lib64/ld-linux-x86-64.so.2 \ /nix/store/jms7zxzm7w1whczwny5m3gkgdjghmi2r-glibc-2.42-51/lib/ld-linux-x86-64.so.2or
patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2on the downloaded binary, which survives the store hash changing next time the binary is rebuilt. Debian's glibc 2.41 runs the 2.42 built binary without complaint.Worth noting the wrapper has a
--dockerpath too, which isn't much use when you're already inside a container.5. Frontend build OOMs on a 6GB Docker VM
bunx vite buildtransforms about 8,962 modules and dies at exit 134,node::OOMErrorHandler. Node's default heap inside a 5.8GB VM isn't enough. Scoping the flag to the one script fixes it:Setting
NODE_OPTIONSon the container instead is a trap: it changes Bun's module loading and brings the graphql error in item 3 back in processes that were otherwise fine.After all five
Full stack comes up green: local Midnight node producing blocks, indexer, proof server on
:6300/health, both Hardhat chains with contracts deployed, Compact contract compiled and deployed, sync node answering:9999/api/erc721, batcher, frontend on:10599.The local Midnight node plus proof server is the reason I went with this template over rolling my own, so getting it to a clean-clone build seems worth doing. Say the word and I'll send the PR.