> For the complete documentation index, see [llms.txt](https://docs.reviactyl.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reviactyl.app/development/extensions/packaging-extension.md).

# Packaging Extension

Package and Compile your Extension

Once your extension works under the dev link, you package it into a single file others can install. That file has the extension `.rext`.

### Before you package

Run through this quickly:

* &#x20;`extension.json` is valid, with a sensible `id`, `version` and `api_version`.
* Your frontend is built (`php artisan d:extensions:watch my-extension --once`) so `frontend/dist` is up to date.
* Every `module` path in the manifest points at a file that exists.
* No path in the package contains `../`.
* You've removed the dev link, or at least you know it's there: `php artisan d:extensions:dev my-extension --unlink`.

### Build the package

```bash
php artisan d:extensions:compile
```

This packages your extension. The example extension's README passes the extension ID:

```bash
php artisan d:extensions:compile my-extension
```

Passing the ID is the safer habit if you have more than one extension in development. If your panel complains about the argument, drop it.

### What's inside a `.rext`

A `.rext` is a plain ZIP archive. You can open it with any unzip tool to check what you're shipping. The example's package contains:

```
backend/routes/client.php
backend/Extension.php
extension.json
frontend/src/dashboard.tsx
frontend/src/dashboardx.tsx
frontend/src/server-route.tsx
frontend/src/dashboard-route.tsx
frontend/dist/dashboard.js
frontend/dist/dashboardx.js
frontend/dist/server-route.js
frontend/dist/dashboard-route.js
```

Two things to notice:

* **`extension.json` sits at the root** of the archive, not inside a wrapper folder. If you ever zip an extension by hand, zip the *contents* of the folder, not the folder itself.
* **Both `src` and `dist` are included.** The compiled JavaScript is what runs; the source travels with it.

List the contents of your own package to confirm:

```bash
unzip -l my-extension.rext
```

### Test the package like a user would

A package that works under the dev link can still be broken, for example by a missing file. Test the real install path on a clean panel.

The example's README describes the install flow. Copy the `.rext` into the panel root, then:

```bash
php artisan extension:install my-extension
php artisan extension:enable my-extension
```

(These are the singular spellings from the example README; the docs site's equivalents for the other commands are plural, so check `php artisan list | grep extension` if one isn't found.)

Then confirm:

1. `php artisan extensions:list` shows it, enabled.
2. Your pages appear and your slots render.
3. Your backend routes respond.
4. Disabling it (`php artisan extensions:disable my-extension`) removes your pages cleanly.

### Versioning

Bump `version` in `extension.json` every time you cut a new package. Use `MAJOR.MINOR.PATCH`, as the example's `0.1.0` suggests. A `0.x` version tells people the extension is still settling.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.reviactyl.app/development/extensions/packaging-extension.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
