npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@intentic/extension-manifest

v1.394.0

Published

What an intentic extension DECLARES, the intentic-extension.json schema and the sandbox-route allowlist rule

Readme

extension-manifest

The schema of intentic-extension.json: what an extension declares it contributes and may reach, which the install dialog shows and the host holds every registration to.

flowchart LR
    points["src/points/<br/>one file per contribution point"] --> manifest(["ExtensionManifestSchema"])
    manifest -- "manifestJsonSchema" --> schema["intentic-extension.schema.json<br/>author's editor hover text"]
    manifest --> daemon["Daemon<br/>install · updates · route gate"]
    manifest --> web["Editor<br/>install dialog · extension host"]
    manifest --> scan["registry-scan<br/>readiness checks"]
  • manifest.ts is the envelope. Each contribution point (views, commands, capabilities, listener, processes and the rest) is a ContributionPoint in src/points/, carrying the sentence an author sees as hover text.
  • The runtime parse is lenient and the authoring schema strict, since an unknown key in an author's file is a typo. The generated schema is committed twice, here and in the site's public/ behind MANIFEST_SCHEMA_URL, and the editor's manifest-schema.test.ts fails when either copy is stale.
  • A cli card whose credential is a delegated OAuth sign-in declares refreshToken (the secret field it lives in and the fields it is bound to), so its own CLI and listener can store a new or rotated token through the daemon's write-only oauth-token route instead of printing it for someone to paste, and probe.oauth, which trades the token for an access token before the card's connection test (Microsoft's identity platform only, today).
  • sandboxRouteAllowed is the permission rule: an entry is "<METHOD> <path-glob>", and each * stands alone between slashes and matches one whole path segment, never a . or .. the URL would resolve away. A malformed entry (**, a * inside a segment, an unknown method, a relative path) fails the manifest parse rather than the first call it gates.
  • extensionRouteReach is the whole rule for an extension's own token: the two routes every extension reaches about itself (EXTENSION_OWN_ROUTES: its settings and its event stream), its own listener provider's routes, and whatever permissions.daemon declares. The daemon's grant and the SDK's test fake both judge by it, and ./permissions exports the rule alone, for a process that should not load the manifest schema.
  • What a field MEANS to the host is declared on the field, with .meta({ power, effect, mintsServer }) (meaning.ts), and read from there: the powers diffPowers folds a manifest into (so an update re-asks only when it adds one), the effects a card discloses in the capability catalog, and the capability kinds whose ids become mcp__<id>__ servers in the contract's reserved-name check. A new field is either given a meaning where it is defined or has none.
  • toolServersOf is the one reading of which MCP servers a manifest serves the agent: contributes.tools, or a cli card's mcp, its alias for one release. A superRefine on the envelope says what no single field can: tools need a server bundle or a declared process to serve them.
  • HOST_PUBLISHED_SPECIFIERS lists the only bare imports a published bundle may use: the modules the shell's import map provides. bundleProblem finds a bundle's imports with a small tokenizer rather than a line regex, since a minified bundle puts them all on one line and a string or comment may spell the word.
  • The same reading names what each static import takes (bundleImportedNames: RepoRail of import { RepoRail as e }, default of a default import). missingImports compares that with what a host's modules export, which the caller hands in, and bundleProblem says it in words when given them. The editor's loader runs it before linking a bundle, over only the imports at the bundle's head (leading), where a bundler puts them all. That takes a fraction of a millisecond where reading a 700 KB bundle whole took about 20 (2026-10-15), and an import it does not reach fails to link as it would have.

Key files

Commands

pnpm --filter @intentic/extension-manifest schema   # regenerate both copies of the authoring schema
pnpm --filter @intentic/extension-manifest test     # the bundle scanner, the permission grammar, every power counting