Restore Fresh 2 compatibility in Fedify#639
Restore Fresh 2 compatibility in Fedify#639dahlia merged 5 commits intofedify-dev:2.0-maintenancefrom
Conversation
Remove the CommonJS-only multicodec dependency from the multibase public key path in @fedify/vocab-runtime. This keeps key handling inside Fedify and avoids the Vite SSR crash that prevented Fresh 2 apps from importing @fedify/fedify without an externalization workaround. This also removes the temporary Fresh workaround from the example and integration guide, and updates the changelog for the regression. Fixes fedify-dev#621
Switch the source-facing JSON-LD imports used by Fedify to the package's ESM entrypoint so Deno, Cloudflare Workers, and other source-based runtimes do not have to go through CommonJS interop. This also updates the code generator regression test and the Fresh example used for manual verification. fedify-dev#621
Deno 2.7.7 fixes the upstream Fresh/Vite dev server crash that prevented final verification of the Fedify fixes for Fresh 2. Update the repository's default Deno version and document the known-good baseline for the Fresh integration example. fedify-dev#621 https://github.com/denoland/deno/releases/tag/v2.7.7
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly improves Fedify's compatibility with Fresh 2 by eliminating problematic dependency paths that caused SSR failures. By replacing the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request effectively resolves Fresh 2 compatibility issues by replacing the problematic multicodec dependency with a well-tested internal implementation and by switching to an ESM-safe import for jsonld. The changes are thorough, including updates to tests, documentation, and examples. My main feedback is a suggestion to improve type safety by adding a custom declaration file instead of using @ts-ignore for the jsonld import, which would enhance long-term maintainability.
A local declaration keeps the jsonld ESM deep import typed without silencing the checker in the linked data signature code. The same change is applied to the vocab code generator so generated sources and snapshot expectations stay aligned. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
A local declaration keeps the jsonld ESM deep import typed without silencing the checker in the linked data signature code. The same change is applied to the vocab code generator so generated sources and snapshot expectations stay aligned. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
A local declaration keeps the jsonld ESM deep import typed without silencing the checker in the linked data signature code. The same change is applied to the vocab code generator so generated sources and snapshot expectations stay aligned. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
Codecov Report❌ Patch coverage is
... and 1 file with indirect coverage changes 🚀 New features to boost your workflow:
|
A local shim module keeps the jsonld ESM deep import isolated without ambient declarations that JSR rejects during publish. The same change is applied to the vocab code generator so generated sources and snapshots stay aligned across Deno, Node.js, and Bun. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
Move the jsonld ESM shim into @fedify/vocab-runtime and expose it through the new jsonld subpath export. This avoids fragile relative imports in generated vocab sources while keeping JSR-safe packaging for the deep jsonld ESM entrypoint. Update Fedify's Linked Data signature code, the vocab code generator, snapshots, and CHANGES.md to use the shared runtime module. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
Move the jsonld ESM shim into @fedify/vocab-runtime and expose it through the new jsonld subpath export. This avoids fragile relative imports in generated vocab sources while keeping JSR-safe packaging for the deep jsonld ESM entrypoint. Update Fedify's Linked Data signature code, the vocab code generator, snapshots, and CHANGES.md to use the shared runtime module. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
Move the jsonld ESM shim into @fedify/vocab-runtime and expose it through the new jsonld subpath export. This avoids fragile relative imports in generated vocab sources while keeping JSR-safe packaging for the deep jsonld ESM entrypoint. Update Fedify's Linked Data signature code, the vocab code generator, snapshots, and CHANGES.md to use the shared runtime module. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
Move the jsonld ESM shim into @fedify/vocab-runtime and expose it through the new jsonld subpath export. This avoids fragile relative imports in generated vocab sources while keeping JSR-safe packaging for the deep jsonld ESM entrypoint. Update Fedify's Linked Data signature code, the vocab code generator, snapshots, and CHANGES.md to use the shared runtime module. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
Move the jsonld ESM shim into @fedify/vocab-runtime and expose it through the new jsonld subpath export. This avoids fragile relative imports in generated vocab sources while keeping JSR-safe packaging for the deep jsonld ESM entrypoint. Update Fedify's Linked Data signature code, the vocab code generator, snapshots, and CHANGES.md to use the shared runtime module. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
Move the jsonld ESM shim into @fedify/vocab-runtime and expose it through the new jsonld subpath export. This avoids fragile relative imports in generated vocab sources while keeping JSR-safe packaging for the deep jsonld ESM entrypoint. Update Fedify's Linked Data signature code, the vocab code generator, snapshots, and CHANGES.md to use the shared runtime module. fedify-dev#639 (comment) Co-Authored-By: OpenAI Codex <codex@openai.com>
|
Pre-release has been published for this pull request: Packages
|
Summary
This PR restores Fresh 2 compatibility in Fedify by removing two SSR-hostile dependency paths and by validating the Fresh example end-to-end on Deno 2.7.7.
Closes #621.
Changes
multicodecdependency in packages/vocab-runtime/src/key.ts with an internal multicodec/varint helper implemented in packages/vocab-runtime/src/internal/multicodec.ts.multicodecdependency from the relevant manifests, including packages/vocab-runtime/deno.json and packages/vocab-runtime/package.json.@fedify/vocab-runtime/jsonldsubpath export in packages/vocab-runtime/src/jsonld.ts so Fedify and generated vocabulary code can share one JSR-safe wrapper around thejsonldESM entrypoint.@fedify/vocab-runtime/jsonldinstead of depending on fragile relative shims or the package-rootjsonldentrypoint.Investigation
This issue turned out to have multiple layers rather than a single Fresh-specific bug.
The first failure reproduced in Fresh 2 SSR was
TypeError: varint.encode is not a function. Tracing the import graph showed that the failure came from the multibase key path in packages/vocab-runtime/src/key.ts, which depended onmulticodec. That package was safe enough in other environments but became fragile when evaluated through Fresh 2's SSR toolchain. Since Fedify only needs a very small subset of multicodec behavior there, the most robust fix was to stop depending on the package at runtime and replace it with a local helper that only handles the supported prefixes and varint encoding and decoding logic.After that change, the original error disappeared, but Fresh still failed in a different place with
buildHeaders is not a function. That pointed to a second SSR-hostile path: the defaultjsonldentrypoint. The important detail here was that Fresh users typically consume Fedify through JSR, so fixing only npm build artifacts under dist/ would not have solved the actual problem. The real fix had to happen in the source modules that are published to JSR, which is why this PR changes the imports in packages/fedify/src/sig/ld.ts and in the generated vocabulary source path produced by packages/vocab-tools/src/class.ts.The first version of that fix switched those imports directly to
jsonld/dist/jsonld.esm.js, which solved the runtime issue but still left two structural problems. First, generated code had to rely on a package-local shim file through a relative import, which was more fragile than necessary. Second, adeclare moduleapproach for typing that deep import turned out to be incompatible with JSR publishing because JSR rejects packages that modify global types. The final shape in this PR is therefore a dedicated@fedify/vocab-runtime/jsonldsubpath export. It centralizes the deep import in one runtime package that generated vocab code is already meant to depend on, avoids relative-path coupling in generated sources, and remains valid for both JSR and npm packaging.Once those two Fedify-side issues were fixed, Fresh dev mode still crashed, but the error had changed again to
The service is no longer running: Callback called multiple timeswhile evaluatingfresh/build-idthrough Vite. At that point the failure no longer implicated Fedify directly. Verifying against Deno release information and rerunning the example on Deno 2.7.7 showed that this remaining crash was an upstream Deno regression in 2.7.6 rather than another Fedify bug. In other words, the Fedify fixes in this PR remove the SSR incompatibilities that belonged to Fedify itself, and the final end-to-end verification succeeds once the underlying Deno regression is no longer present.One smaller follow-up that surfaced during verification was that
mise run test:bunstill failed even after the functional fixes were complete. That was not a runtime regression but a stale snapshot in packages/vocab-tools/src/snapshots/class.test.ts.snap, which still expected the older import path after the generator had been updated. Refreshing the Bun, Node.js, and Deno snapshots brought all three runtimes back in line.Benefits
These changes remove the need for the previous Fresh SSR workaround, make the fix apply to both the JSR and npm package paths instead of only one packaging format, and keep the affected code paths portable across Deno, Node.js, Bun, and Cloudflare Workers.
Verification
@fedify/vocab-runtime/jsonldruntime path.deno task devanddeno task build./,/nodeinfo/2.1, and/users/samplewithAccept: application/activity+json.varint.encode is not a functionandbuildHeaders is not a functionno longer reproduce.deno publish --dry-run --allow-dirtysucceeds in both packages/vocab-runtime/ and packages/vocab/.mise run test:bunpasses after refreshing the runtime-specific snapshots.Checklist
mise teston your machine?Additional notes