Skip to main content

Creating New Packages

Sometimes the correct answer is not "extend an existing package."

Sometimes the correct answer is "create a new package."

When To Create A New Package​

Create a new package when the feature is:

  • a distinct domain
  • a new runtime family
  • a new execution format
  • a new build or platform provider
  • a new tooling surface

If the feature would distort an existing package's ownership boundary, create a sibling package.

Minimal Package Skeleton​

morphs/MyPackage/
  morph.toml
  features/
    my_feature/
      feature.toml
      ...
  blocks/
    my_surface/
      block.toml
      Syntax.cpp
  plugin/

Add blocks/ when the package introduces new [forms.*] grammar. Add runtime/ or backend/ only if the package actually owns those layers.

Minimal Manifest​

[package]
domain = "my_package"
owner = "Morph"
abi = 1

[include]
files = [
  "features/*/feature.toml",
  "blocks/*/block.toml",
]

Omit the blocks/ line until you have a blocks/ tree; [include] must match reality or fragments never load. This is the starting point, not the final package.

Package Design Questions​

Before creating the package, decide:

  • what domain it owns
  • what it explicitly does not own
  • whether it needs runtime ownership
  • whether it needs backend ownership
  • whether it needs tooling, execution, or build descriptors

If these are unclear, the package boundary is probably not ready yet.

Framework Widening Still Exists​

Creating a new package does not mean the framework is always already sufficient.

If the new package needs a hook that Morph cannot express today:

  1. add the generic framework or SDK capability
  2. use that new capability from the package

Do not bypass the framework by putting package ownership into core.

Next Steps​