⬆️ Upgrade www to revolution 0.9 and Effection v4 - #1258
Merged
Merged
Conversation
Revolution 0.9 is the first release built against Effection v4, so the two move together. It is published to npm, which retires the last deno.land/x imports the site had: revolution itself, and a private `std@0.203.0` module aliased as `_posixNormalize`, now the public `@std/path/posix/normalize`. The site's own code needs no changes. It uses no `action()` and never passes a promise to `call()`, so nothing it does changed meaning in v4. The @effectionx packages move from jsr to npm because only the npm builds accept `effection@^4`; their jsr builds are pinned to ^3. `@effectionx/watch` is dropped. Its jsr build is pinned to ^3 and picks up the site's effection through the import map, so it now fails on startup, and its npm build publishes no `bin` to run instead. Deno's own `--watch` restarts the site on a source change, which is all the task was asking for.
The jsr build is pinned to effection ^3 and resolves the site's effection through the import map, so it fails on startup against v4. The npm build accepts ^3 || ^4, but publishes no `bin`, so `deno run -A @effectionx/watch` cannot find anything to run. Its CLI is the package's main export, so importing it runs it. A two line module does that, and the task invokes the module.
@effectionx/watch 0.4.8 declares a `bin`, so the task can invoke the package instead of a module that imports it for its side effects.
cowboyd
approved these changes
Oct 3, 2026
commit: |
Contributor
|
🚀 Deploy Preview Ready!
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Important
Both upstream releases are out:
@frontside/revolution@0.9.1and@effectionx/watch@0.4.8. CI still fails until 2026-10-04 11:34 UTC, when revolution 0.9.1 clears Deno's 24 hour minimum dependency age. Everything below was verified locally against the published packages.Motivation
The site still ran on Effection v3. Revolution 0.9 is the first release built against v4, so the two have to move together.
Doing it also takes the site off
deno.land/xentirely, which was the second half of the ask. Two imports came from there:revolutionandrevolution/jsx-runtime, pinned at0.6.1_posixNormalize, an alias forhttps://deno.land/std@0.203.0/path/_normalize.ts— a private module (leading underscore) of a std release from 2023Approach
The site's own code did not change
It uses no
action()and never passes a promise tocall(), so nothing it does changed meaning in v4. The entire diff iswww/deno.jsonplus one import line.Why not
deno.land/x/revolution@0.8.00.8.0 runs on whatever effection the consumer supplies, so it would have worked. It is not worth taking: it imports nine bare specifiers, and a remote module resolves those against the workspace root import map rather than
www's. Getting it to type-check meant adding a nine-entryscopesblock to the repository root to serve one dependency of one workspace member.Why 0.9.0 could not be used either
@frontside/revolution@0.9.0cannot be imported at all. It ships 28 bare import statements across nine packages and declares none of them, with nothing vendored:Three of those (
@std/http,@std/path,esbuild-deno-loader) are JSR-only and have no npm package under that name, so no consumer can supply them. thefrontside/revolution#26 fixes it at the source — a dnt bump that vendors the JSR modules, plus a mapping that keepseffectiona genuine peer dependency rather than a second private copy.@effectionx packages move from jsr to npm
Only the npm builds accept
effection@^4; the jsr builds are pinned to^3.@effectionx/watch keeps working, on its npm build
Its jsr build is pinned to
^3and resolves the site's effection through the import map, sodeno task devdies on startup:The npm build accepts
^3 || ^4, but publishes nobin:thefrontside/effectionx#261 declares the
bin, released as0.4.8, so the task staysdeno run -A @effectionx/watch deno run -A main.tsxand only the version pin moves.Verification
Run against the published
@frontside/revolution@0.9.1and@effectionx/watch@0.4.8from npm, with no local patching. The published revolution tarball matches the candidate exactly:@stdand@lucavendored, no vendoredeffection, dependencies declared.deno check main.tsx— cleandeno fmt --check(143 files),deno lint(120 files) — cleandeno task test— 10 passed, 29 stepsdeno task smoke— 7 passeddeno task dev— boots, restarts gracefully on a source change, serving again 16s later/,/api,/api/v4/main,/guides/v4/operations,/x/task-buffer,/blog,/AGENTS.md,/llms.txt,/api.md,/blog/feed.xml,/sitemap.xml, and every asset the home page referencesdeno task staticalize— 719 pages, 21 assets, 11.9 MB, zero failures;sitemap.xmlandblog/feed.xmlparse as well-formed XML and canonical links are intactnode_modulesholds exactly oneeffection, resolved from the site, so revolution shares its scopes rather than running a private copyNote on
deno task testUnrelated to this PR, but worth recording:
www/deno.jsonsetsfmt.excludeandlint.excludeforbuild, but there is notest.exclude. Once the site has run once,deno task testglobs the hundreds of*.test.tsfiles underwww/build/clones/and fails with ~377 type errors. Removingbuild/makes it pass. Worth a separate fix.