Skip to main content

Contributing to Bilup

Bilup is a Scratch modification built on top of TurboWarp, which is itself built on Scratch. That lineage matters for contributors: most of the code you will read is regular Scratch/TurboWarp code, and the Bilup-specific pieces sit on top of it. If you have contributed to Scratch or TurboWarp before, you already know most of what you need.

This section is for people who want to work on Bilup itself: fixing bugs in the editor, adding blocks to the VM, writing addons, or running their own build. If you only want to build a custom extension for your projects, read Building Extensions instead, which does not require checking out the source.

What lives where​

Bilup is not a single repository. It is a small collection of forked Scratch packages plus a few Bilup-only services, checked out side by side. The Project Structure page describes the full layout, but the short version is:

  • scratch-gui is the editor and the community site, built together in one webpack build. This is where you will spend most of your time.
  • scratch-vm runs projects and contains the compiler. Blocks are defined here.
  • scratch-render, scratch-blocks, scratch-paint, and scratch-audio are the other forked engine packages.
  • packager turns projects into standalone HTML/executables.
  • mistwarp-api is the community platform backend.
  • docs is this site.

Before you start​

  • Bilup is a large app. Building the editor can use several gigabytes of disk space and memory.
  • You need Git and a recent Node.js (v20 is what we develop against; v18 or later is likely fine).
  • scratch-gui uses pnpm as its package manager, not npm. See Building and Running.

How to read the rest of this section​

  1. Project Structure explains the multi-repo layout and how the packages link together.
  2. Building and Running is the practical setup: clone, install, link, run.
  3. Testing covers the test suites in scratch-gui and scratch-vm.
  4. Contributing covers the workflow: branches, style rules, and pull requests.
  5. Deploying explains how a build is published, in case you run your own instance.

If you want to understand how the editor is put together before you change it, the Internals section is the companion to this one.

See also​