You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide an AI tool that can quickly check and convert npm packages into packages compatible with Perry? #115
Thanks for the suggestion! I've been thinking about this and I want to push back on it a bit — not on the goal (making npm packages work with Perry), but on the shape (a dedicated Perry AI tool).
Why I don't think a bespoke tool is the right move:
General coding agents — Claude Code, Codex, Cursor, Aider — are already very good at exactly this task. You can literally say "read this npm package, figure out what Perry's TypeScript subset doesn't support, and patch it" and they'll do it. A Perry-specific wrapper around one of these would duplicate their work and rot faster than the underlying agents improve. I'd rather the project not own something that's strictly worse six months from now.
What Perry already has:
The runtime half is done. package.json accepts a perry.compilePackages field that pulls the listed packages into the native compile and dedups them:
So the mechanical side — "how do I get this package into the binary" — isn't the hard part. The hard part is knowing which patches a given package needs.
What I think would actually help:
A porting guide in the docs — something like docs/src/packages/porting.md — covering:
Perry's TypeScript subset gaps (the known categorical ones: lookbehind regex, some console.* formatting, a few typed-array edge cases)
Common patterns that break (dynamic require, eval, certain Node internals)
A prompt template you can paste into any coding agent to drive the port
That's a few hours of work, lives in the repo, and doesn't become obsolete when the agents get better. If you (or anyone) wants to take a crack at drafting that guide, I'd happily review a PR.
Going to leave the issue open for now in case others want to weigh in on the docs angle, but I'm leaning toward closing it as "won't build, will document instead."
@WREQI good suggestion — a skill is a cleaner fit than a bespoke tool for exactly the reason I was pushing back on earlier: it's just markdown that any skill-aware agent can consume, so it doesn't rot when the underlying agents improve. Same content lives as a plain doc for everyone else.
.claude/skills/port-npm-to-perry/SKILL.md — agent-invocable skill that walks through: locate package → scan for known gaps (with concrete greps) → triage what's patchable vs. what rules the package out → wire up perry.compilePackages → apply minimal patches → record them in perry-patches/<name>.md so npm install doesn't blow them away → verify.
docs/src/packages/porting.md — human-readable companion with the same content plus a paste-able prompt template for Cursor/Aider/Codex and other agents that don't consume the skill format.
Both are marked experimental at the top, with a pointer back here. The hard part isn't the mechanics — it's knowing which packages are actually portable (pure TS/JS, patchable gaps) vs. dead ends (native addons, Proxy-as-public-API), and that judgment will only get sharper with real porting reports. If either of you ports a package and the skill misses a gap, or makes a bad patching call, please comment here — that's the feedback loop I care about.
Leaving this open as the feedback channel for the skill itself.
Currently, many applications developed using Perry (editor, Bloom Engine...) have accumulated best practice AI skills. Are there plans to open up AI skills? A separate AI skills repository?
Hermes Agent https://hermes-agent.nousresearch.com/docs/
Have you used this agent? Perhaps it can be synchronized for use, making it easier to automatically deposit and publish some of your skills, so that we can directly download and use them
Activity
proggeramlug commentedon Apr 21, 2026
Thanks for the suggestion! I've been thinking about this and I want to push back on it a bit — not on the goal (making npm packages work with Perry), but on the shape (a dedicated Perry AI tool).
Why I don't think a bespoke tool is the right move:
General coding agents — Claude Code, Codex, Cursor, Aider — are already very good at exactly this task. You can literally say "read this npm package, figure out what Perry's TypeScript subset doesn't support, and patch it" and they'll do it. A Perry-specific wrapper around one of these would duplicate their work and rot faster than the underlying agents improve. I'd rather the project not own something that's strictly worse six months from now.
What Perry already has:
The runtime half is done.
package.jsonaccepts aperry.compilePackagesfield that pulls the listed packages into the native compile and dedups them:{ "perry": { "compilePackages": ["@noble/curves", "@noble/hashes"] } }So the mechanical side — "how do I get this package into the binary" — isn't the hard part. The hard part is knowing which patches a given package needs.
What I think would actually help:
A porting guide in the docs — something like
docs/src/packages/porting.md— covering:console.*formatting, a few typed-array edge cases)require,eval, certain Node internals)That's a few hours of work, lives in the repo, and doesn't become obsolete when the agents get better. If you (or anyone) wants to take a crack at drafting that guide, I'd happily review a PR.
Going to leave the issue open for now in case others want to weigh in on the docs angle, but I'm leaning toward closing it as "won't build, will document instead."
WREQI commentedon Apr 22, 2026
ok，Perhaps a standard skill can be provided to help AI strengthen processing?
docs: port-npm-to-perry skill + porting guide (experimental, re #115)
proggeramlug commentedon Apr 22, 2026
@WREQI good suggestion — a skill is a cleaner fit than a bespoke tool for exactly the reason I was pushing back on earlier: it's just markdown that any skill-aware agent can consume, so it doesn't rot when the underlying agents improve. Same content lives as a plain doc for everyone else.
Shipped an initial pass in df39fda:
.claude/skills/port-npm-to-perry/SKILL.md— agent-invocable skill that walks through: locate package → scan for known gaps (with concrete greps) → triage what's patchable vs. what rules the package out → wire upperry.compilePackages→ apply minimal patches → record them inperry-patches/<name>.mdsonpm installdoesn't blow them away → verify.docs/src/packages/porting.md— human-readable companion with the same content plus a paste-able prompt template for Cursor/Aider/Codex and other agents that don't consume the skill format.Both are marked experimental at the top, with a pointer back here. The hard part isn't the mechanics — it's knowing which packages are actually portable (pure TS/JS, patchable gaps) vs. dead ends (native addons, Proxy-as-public-API), and that judgment will only get sharper with real porting reports. If either of you ports a package and the skill misses a gap, or makes a bad patching call, please comment here — that's the feedback loop I care about.
Leaving this open as the feedback channel for the skill itself.
WREQI commentedon Apr 23, 2026
Currently, many applications developed using Perry (editor, Bloom Engine...) have accumulated best practice AI skills. Are there plans to open up AI skills? A separate AI skills repository?
proggeramlug commentedon Apr 23, 2026
@WREQI thats actually a great idea, let me think about that!
WREQI commentedon Apr 25, 2026
Hermes Agent
https://hermes-agent.nousresearch.com/docs/
Have you used this agent? Perhaps it can be synchronized for use, making it easier to automatically deposit and publish some of your skills, so that we can directly download and use them
fix(hir+runtime): #838 — JS-classic prototype-method dispatch (Class.…
proggeramlug commentedon Jun 23, 2026
@WREQI At this point Perry can compile most npm packages :) So I'm closing this as no longer needed.