# teleport-code-generators: one UIDL, several framework outputs

> teleport-code-generators is the TypeScript engine behind the teleportHQ visual editor, and its core idea is that a user interface should be described once in an abstract form, the UIDL, and then compiled to React, Vue, Angular, Web Components, Preact, React Native or Stencil. The repository is a lerna and yarn workspace monorepo of npm packages, and the README is explicit that the project is still short of a first official version.

**teleporthq/teleport-code-generators** — A collection of code generators for modern JavaScript applications

- Repository: https://github.com/teleporthq/teleport-code-generators
- Website: https://teleporthq.io
- Stars: 1,117 · Forks: 184
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/teleporthq-teleport-code-generators

## The UIDL is the contract between the editor and the code

teleportHQ is a low-code platform that enables teams to build applications through a familiar design tool interface in real time, and this repository holds the code generators that power the visual editor of that platform.

The glue between the platform and the generators is the UIDL Standard, and that is the architectural centre of the whole project. The UIDL defines user interfaces in an abstract way, independent of any framework or even the web platform itself. Starting from the UIDL, you can convert that abstraction into different flavors of coding, React, Vue, WebComponents and so on.

The philosophy behind the code generators is listed as five points, and they are the design brief for anyone extending the project.

User interfaces are decomposed into components, hence the focus on component generation. What can be built with React can also be built with Vue or on top of the Web Components standard, so multiple targets are supported. A project built with the visual editor should have a high standard of quality, with performance, security and accessibility included. Generated code quality should be as high as possible, so that any developer could pick up the work from there on and enhance the project. And the code generation architecture is open and extendable, with the project inviting contributions.

That last point, about the generated code being something a developer would want to own, is the requirement that makes this more than a template expander.

## A UIDL is a JSON tree of elements and static content

The quick setup says that generating a simple component means starting from a component UIDL, and the example is short enough to read as the data model.

```json
{
  "name": "My First Component",
  "node": {
    "type": "element",
    "content": {
      "elementType": "text",
      "children": [
        {
          "type": "static",
          "content": "Hello World!"
        }
      ]
    }
  }
}
```

Two node types appear here. The element node carries an elementType, which is the semantic role of the thing on screen, text in this case, and a children array. The static node carries literal content.

The elementType is the important field, because it is the level at which the abstraction stops. The UIDL does not say span or div, it says text, and each target decides what that becomes. The React output for the same UIDL is a span, and the Vue output is a span inside a template block, so the mapping from elementType to concrete tag is per-flavor, which is exactly the point of separating the description from the target.

The names of the node types are also the extension surface. A generator that understands element, static, and whatever else the standard defines can produce anything the standard can express, and the set of understood types is the ceiling on what any target can render.

## Generating a component, and switching target by changing the import

Using the pre-configured component generators is as easy as calling an async function.

```javascript
import ReactGenerator from '@teleporthq/teleport-component-generator-react'

const uidl = { ... } // your sample here

const { files } = await ReactGenerator.generateComponent(uidl)
console.log(files[0].content)
```

The return value is a files object, and each entry has content, which is the generated source for one file. The React output for the sample is a functional component with a default export.

Switching targets is a single import change.

```javascript
import VueGenerator from '@teleporthq/teleport-component-generator-vue'

const uidl = { ... } // your sample here

const { files } = await VueGenerator.generateComponent(uidl)
console.log(files[0].content)
```

The Vue output is a single file component with a template block, a script block and a name derived from the UIDL.

That is the whole promise in one diff. The UIDL did not change, the call did not change, and the output is idiomatic for the target rather than a translation of React into another syntax. A generator that emitted React-shaped code with different brackets would be a much weaker demonstration of the abstraction.

There is also an online REPL at repl.teleporthq.io, where you can edit the UIDL structure and watch the generated code change, alongside examples of components written in the UIDL format. That is the fastest way to judge whether the abstraction expresses the interfaces you actually need.

## Three categories of packages, and how to add your own flavor

The ecosystem section splits the packages into three main categories: component generators, project generators and project packers.

The component generators are the interesting part, and the architecture around them is more open than the package list suggests. All the component generators are exposing an instance of the teleport-component-generator package, and you can install that package yourself and build your own generator with plugins, mappings and postprocessors.

The three extension points are worth separating. A plugin adds new behaviour to the generation pipeline, a mapping relates a UIDL concept to a target-specific implementation, and a postprocessor transforms the generated output after the fact. Together they are what turns a set of shipped generators into a framework, and the docs contain a complete guide on how to build a custom component generator.

There are official component generators for a couple of popular web frontend frameworks, and the flavors listed include teleport-component-generator-react with styling via css-modules. The topic list gives the wider set of targets the project has worked on, including Angular, Preact, React Native, Stencil and Vue.

The plugin architecture is the answer to a fair criticism of code generators, which is that they produce output you cannot control. With postprocessors you can rewrite the emitted code, with mappings you can redirect a UIDL concept to your own component, and with plugins you can add capability. Whether that is enough depends on how far your design system diverges from the defaults.

## A lerna and yarn monorepo, and a pre-commit gate

The repository is a monorepo built around yarn workspaces and lerna, and the root package.json shows the shape.

The workspaces field covers packages/*, and the root is private. The build script runs clean, then link, then function-sources, then lerna run build, and the dev script links, builds and starts a watcher. The test script is jest, with separate entries for performance tests, cache clearing and coverage, and a codecov upload step.

There is a husky configuration with a pre-commit hook that runs pretty-quick on staged files, then the lint script, then many:check. The lint itself is tslint, which is a dated choice for a project whose badge says Prettier is the code style, and the presence of both a .prettierrc.json and tslint.json means formatting and linting are separate concerns here.

Version management is lerna's, with a lerna version script and a lerna-changelog script for the changelog, and the packageManager field requires node 20.x or newer in the engines field. There is also a local publishing setup against a registry on localhost:4873, with scripts to add a user, publish, unpublish and a standalone build for the teleport-test package.

The manypkg tool is used for workspace consistency checks, and it is also a dependency of the root rather than a devDependency, which is a small signal about how the repository is maintained.

## Beta status, and what the release cadence says

The README is candid about where the project stands. It says we are not far from the first official version of the code generators, and that in the meantime some of the parts of the ecosystem are experimental.

That single sentence is the most important thing in the document for an adopter, and it appears in a heading, not a footnote. A code generator that is close to its first stable version will still change its output format, its plugin interfaces and its mapping contract, and a project that generates a whole application rather than one component will see those changes at scale.

The release history is consistent with that. The tags are v0.40.6 from 2025-08-21, v0.36.6 from 2024-10-28 and v0.36.4 from 2024-09-05, so the numbering has moved well past the version named in the README heading, which reads Code Generators v0.21.12 - Beta. The last push was on 2026-10-15, and the default branch is development rather than main, so the published packages and the branch tip are not the same thing.

There is a separate project packer and project generator tier that the README lists but does not detail, and the documentation site at docs.teleporthq.io is where the flavour list, the plugin guide and the UIDL standard are specified. The MIT licence in the root package.json and the LICENSE file is the permissive end of the scale, which is the right choice for a package that a build system will pull into a project.

## Conclusion

teleport-code-generators suits a team that wants one interface description and several framework outputs, or that wants to plug a custom target into an existing generator through plugins, mappings and postprocessors. It is the wrong tool if you need a single target only, since the abstraction and the plugin architecture cost more than writing one generator directly, and it is the wrong choice if you need a stable production API today, because the README says the project is not far from the first official version and that parts of the ecosystem are experimental. Before you build on it, read the UIDL standard documentation, and confirm that the flavor you need is a supported target rather than one of the experimental parts of the ecosystem.

## FAQ

### What is the UIDL Standard in teleport-code-generators?

The UIDL defines user interfaces in an abstract way, independent of any framework or the web platform itself, and it is the glue between the teleportHQ platform and the code generators. Starting from a UIDL you can generate React, Vue, WebComponents and other targets.

### How do I generate a component with teleport-code-generators?

Install a pre-configured generator such as @teleporthq/teleport-component-generator-react, import it, and call the async generateComponent function with a UIDL, which returns a files object whose entries hold the generated content.

### Can I write my own component generator for teleport-code-generators?

Yes. All the component generators expose an instance of the teleport-component-generator package, which you can install and extend with plugins, mappings and postprocessors. The documentation includes a complete guide on building a custom component generator.

### Is teleport-code-generators stable for production use?

The README states the project is not far from the first official version and that some parts of the ecosystem are experimental, and the default branch is development. The most recent tags are v0.40.6 from 2025-08-21 and v0.36.6 from 2024-10-28.

### What licence is teleport-code-generators released under?

MIT, as declared in the root package.json and the LICENSE file at the repository root.

## Sources

- [License: MIT](https://github.com/teleporthq/teleport-code-generators/blob/development/LICENSE)
- [Project website](https://teleporthq.io)
- [README](https://github.com/teleporthq/teleport-code-generators/blob/development/README.md)
- [Releases](https://github.com/teleporthq/teleport-code-generators/releases)
- [teleporthq/teleport-code-generators on GitHub](https://github.com/teleporthq/teleport-code-generators)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/teleporthq-teleport-code-generators