Add Node/PNPM monorepo support for effectionx extensions#1083
Conversation
Implement a new package/workspace abstraction that supports both Deno and Node/PNPM monorepos, enabling the website to read package metadata from effectionx which has migrated from Deno to Node/PNPM. New modules: - lib/registries/ - Registry abstractions for JSR and npm - lib/package/ - Package representation for Deno and Node projects - lib/workspaces/ - Workspace detection and package enumeration Key changes: - Auto-detect workspace type (deno.json vs pnpm-workspace.yaml) - Parse Node package.json exports with conditional export support - Filter hidden packages (e.g., .internal) from listings - Update routes and components to use new useWorkspaces API - Add @std/yaml dependency for parsing pnpm-workspace.yaml
Since effectionx packages are no longer published to JSR, remove all JSR-related fetching and display from the extensions pages. Changes: - Remove getJSRDetails() calls, use package manifest data instead - Remove JSR badge from package headers (keep npm badge only) - Delete ScoreCard component (was entirely JSR-focused) - Remove JSR properties from Package interface - Clean up unused imports and JSR-specific types
Package.json peerDependencies can use OR ranges like '^3 || ^4' which are not valid in Deno npm: specifiers. Sanitize version strings by taking the first part of OR ranges. Also handle workspace: protocol versions by converting to '*'.
commit: |
|
Why do we need a Deno abstraction? |
|
We still use demo for effection and I didn't want to completely get rid of the deno integration in case we decide to use deno again. They might fix all of the problems tomorrow and who knows. |
I'm of two minds here. I would love the ability to go back to Deno, but but until then, this is dead code sitting in our repo, right? If we keep the API, and just have one implementation, that should be enough. I'd rather let the api evolve with our needs according to what we need for the website, and not be burdened by having to keep one foot in each world. |
|
Sounds good |
2 participants
Motivation
The effectionx repository was migrated from Deno to Node/PNPM monorepo structure. The website was hardcoded to read
deno.jsonfiles for package metadata, which no longer works since effectionx now usespackage.jsonandpnpm-workspace.yaml.Additionally, effectionx packages are no longer published to JSR, so the JSR API calls were failing and causing inconsistent display on the
/xpages.Approach
New Monorepo Adapter
Created a new package/workspace abstraction that supports both Deno and Node/PNPM monorepos:
deno.jsonvspnpm-workspace.yamlKey implementation details:
package.jsonexports with conditional export support (usesdevelopmentcondition for source files).internal) from listings^3 || ^4) for Deno npm: specifiersJSR Removal
getJSRDetails()calls - now uses local package manifest data for name/descriptionScoreCardcomponent (was entirely JSR-focused)