# Experimental plugins

Note: This document describes the legacy plugin macro system and is here only
as a reference while we still have some plugins using it around. See
[the top level ffx development docs](/docs/development/tools/ffx/development/README.md)
for documentation on writing subtools.

When developing a new plugin, the experimental (or 'work in progress') nature of
the work is indicated by marking the plugin as experimental.

Experimental plugins:

- Experimental plugins may change their arguments inputs and outputs in every
  IDK release.
- Experimental plugins may _temporarily_ depend on APIs or ABIs that are not
  part of the Fuchsia platform surface area. All dependencies must still be
  defined and represented in the platform source tree.
- Plugin authors must demonstrate a roadmap to non-experimental status, for
  example stabilization of the dependencies of the plugin. It is a goal to
  remove experimental plugins over time to maximize the stability of the ffx
  surface and dependencies.
- Plugins may not introduce behavior that execute at times other than when a
  command from the plugin is invoked (i.e. an experimental plugin can not
  perform background operations in the ffx daemon or Remote Control Service).
- Experimental plugins are subject to the same code review and code quality
  process as other plugins. As experimental plugins are included in the standard
  ffx binary, they must adhere to the same quality standards so as to not affect
  the quality of the product as a whole.

## Mark a plugin as experimental

When defining a plugin function within the plugin lib.rs file, there will be an
entry point decorated with `ffx_plugin` such as:

```
#[ffx_plugin()]
```

or

```
#[ffx_plugin(MyProxy = "fuchsia.example.Service")]
```

To mark a plugin as experimental and simultaneously declare the token used to
enable the experiment, add an initial string parameter. In the following example
the tag "zippy" may (or may not) match the plugin command name. The label may be
arbitrary, but it's recommended to choose a value that relates to the plugin:

```
#[ffx_plugin("zippy")]
```

or

```
#[ffx_plugin("zippy", MyProxy = "fuchsia.example.Service")]
```

In both examples above, the plugin will be guarded by a feature token named
"zippy". When users try to execute `ffx zippy` they will be informed that zippy
is experimental, then instructions for enabling the zippy feature will be shown.

After following the instructions to enable zippy, future calls (for that user)
will operate as if zippy were not experimental, i.e. they have opted-in to using
the zippy feature.

## CL review of experimental code

Experimental plugins must not be used as a mechanism to bypass code quality
concerns, design, security, privacy and other concerns. Every element of ffx
must adhere to a common base standard for inclusion in the IDK.

## Removing the experimental status {#stable-plugin}

Before leaving the experimental state a plugin must have:

- The UX surface is reviewed and sufficiently stable as to adhere to the
  platform versioning RFC.
- The implementation dependencies are all part of the defined platform surface
  area, for example, all FIDL dependencies are sdk_category = 'public'.
- Design doc (accepted by stakeholders)
- User documentation
- Args that comply to the CLI rubric
- Unit tests
- Integration (e2e) tests