Contribute

Weft is built in the open at github.com/WeaveMindAI/weft. The core of the product (the compiler, the executor, the dashboard, the language, the catalog) lives there. If you want to file a bug, request a node, propose a language change, write a PR, or just poke around, everything starts at the repo.

It is a solo project built fast over a few months. The code is young, the patterns are still forming, and some files are bigger than they should be. That is a feature, not a bug, for anyone looking for real things to fix. Early contributors shape the project more than late ones.

Where to start

• The repo. Clone it, run ./dev.sh server and ./dev.sh dashboard, open localhost:5173. You are running the same thing we are.
• README.md. The pitch, the quickstart, and the project layout.
• DESIGN.md. The design principles that filter every PR. If a change fights one of these, it either gets reshaped or dropped. Read it before proposing anything non-trivial.
• CONTRIBUTING.md. How to set up, how the repo is laid out, how to add a node (with a full worked example), PR checklist, and the ground rules for how we argue about code. Read this before opening a PR.
• ROADMAP.md. What is coming, what is being considered, what is intentionally out of scope. Check here before proposing a feature: it might already be planned, or it might be on the "not going to happen" list.

Issues and PRs

Every kind of issue has a template that asks for the right information up front:

• Bug report. Something is broken. Template asks for the repro, the expected behavior, the Weft version, and the logs. Minimal repros ship faster.
• Feature request. Something is missing. Template asks you to justify fit against DESIGN.md. If the change fights a principle, say why the tradeoff is worth it.
• Node request. You need a node that does not exist yet. Template asks for the name, inputs, outputs, and use case. Adding a node is two files, so accepted requests tend to land fast.

For PRs: small fixes (typos, obvious bugs, docs) just open a PR. Medium or large changes (new nodes, refactors, language tweaks) start with an issue. This is in CONTRIBUTING.md too, but it is worth repeating: the worst thing that can happen to a contributor is closing a 500-line PR because the approach did not fit. Talk first.

The language and the compiler

The core of Weft (the parser, the type system, the executor, the group flattening) lives in crates/weft-core/. This is the most opinionated part of the codebase, and the most consequential: a change here affects every project written in Weft.

If you want to contribute to the compiler, read DESIGN.md first, then open an issue describing what you want to change. Compiler changes need a test that fails before the fix and passes after. The test suite lives in crates/weft-core/src/tests/.

Adding a node

The node catalog is where most external contributions will happen, and it is the easiest place to start. Every node is one folder under catalog/<category>/<node_name>/ with two files:

• backend.rs: the Rust implementation (the Node trait).
• frontend.ts: the dashboard UI definition (ports, fields, icon, category).

The inventory crate auto-discovers the new node at startup. The dashboard picks up the new template on the next reload. Adding a node is two files, and the full walkthrough with a working example is in CONTRIBUTING.md.

The dashboard and extension

The dashboard is a SvelteKit + Svelte 5 app in dashboard/. Svelte 5 runes, not legacy reactive statements. The browser extension is in extension/, built with WXT. If you want to improve the UI, fix an accessibility bug, tighten a styling issue, or add a visual polish pass, this is where you go.

Community

Discord is the fastest place to ask a question, show off something you built, or argue with the maintainer. Join, say hi, tell us what you are building.

For longer-form discussions (proposals, architectural arguments, anything that needs a paper trail), use GitHub Discussions. For concrete bugs and features, use GitHub Issues.

How we argue about code

Weft runs on constructive confrontation. Strong disagreement aimed at a decision, a bug, a pattern, or a blocker is welcome, with real heat if that is how you feel. Strong disagreement aimed at a person is not. The test is simple: after the argument, does everyone involved understand the problem better, or does one side just feel worse? The first is the goal.

Full version of this (including why we run this way) is in CONTRIBUTING.md. If you like that framing, you will fit in. If you prefer polite avoidance, there are other projects that will make you happier.