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

@fulcro/transform-core

v1.0.0

Published

Shared machinery behind the Fulcro compile time transformers. Installed for you; not meant to be depended on directly.

Downloads

1,644

Readme

@fulcro/transform-core

Shared machinery behind the Fulcro compile time transformers.

You do not install this. @fulcro/reflect depends on it, and any other package in the library that grows a transformer will too. It is published because they depend on it, not because it is meant to be used directly, and its shape is theirs to change without notice.

If you are looking for the compiler plugin, it lives in the package whose calls it rewrites:

{ "plugins": [{ "transform": "@fulcro/reflect/transformer" }] }

Why it exists

The library used to ship one transformer, @fulcro/transformer, installed beside @fulcro/reflect as a peer dependency. Two things were wrong with that.

It could go missing. npm installs peer dependencies and Yarn does not, so a project could end up with the utilities and no transformer. The failure was quiet, because the utilities are built to degrade rather than crash: defaultOf throws, nameOf falls back to parsing closures, typeOf(…).declared reads null. Nothing says your build is missing a plugin.

It could go out of step. @fulcro/[email protected] with @fulcro/[email protected] was an installable, broken combination, because what a call means and what it compiles to were versioned separately.

Both disappear when the transformer ships inside the package whose calls it rewrites. What is left over is the part that belongs to no package in particular — and that is this one.

What is in here

Everything with nothing to do with any particular utility:

| Piece | Does | | --------------------------- | --------------------------------------------------------------------------- | | isOwnedCall | Follows a call back to the declaration that owns it, rather than by name | | createTransformer | Walks a source file once and hands each call to the rewriter that claims it | | createFileTransformer | Builds and keeps a program, for the bundlers that have no checker | | createTransformerUnplugin | The adapter surface Vite, Rollup, Webpack, Rspack, esbuild and Farm expect |

What lives in each library instead is the part that knows what to emit — how defaultOf fills a tuple, how a type argument becomes a runtime test. That split is why a package can own its compile time behaviour without a second install, and why two of them can do so without knowing about each other.

TypeScript 5 and 6 only

{ "typescript": ">=5.3.3 <7" }

7.x is the native port, and its package no longer exposes the compiler API this is built on. Declared as an optional peer dependency, so that a project only using the runtime half of a library never has to install a compiler it is not going to run.

Licence

ISC.