Curating your import

Configuration overview

Interplay requires 2 things to run your code:

  • A build of your components.
  • A JSON configuration file that describes your components, props, presets, tokens and build files.

By default when you run the CLI, it bundles your code and aims to generate config for all your components, all their props, all their available metadata and all matching presets (according to your import settings).

Why Curate?

If our code repo is the source of truth, why curate the import?

There are a few common reasons why you'd want to curate the 'everything' imported by default:

  • Hiding component props that are not relevant to designers
  • Providing guidance on how to use the components that is not enforced in the code e.g. by adding descriptions or constraints to simplify the design-tool experience
  • Correcting or adding information that could not be detected via parsing the code
  • Creating designer-friendly presets of common usage (e.g. Menu pre-filled with MenuItems)
  • Organising components into folders

Curating your import is optional - you can leave your components and props configuration unchanged and work with them in Figma and Interplay as imported.

Approaches to curating

There are 3 ways of curating your imported configuration as outlined below.

You can use a combination of these to manage different parts of your configuration.

1. Curating in Interplay

Perhaps the most convenient way of changing your configuration is by updating the imported configuration online in your Project.

For example you can:

  • Update a component description to explain when it should be used
  • Set developer-only props to hidden so they are not displayed
  • Restrict the allowed child components for a component to guide your designers in how to use the system.

Updates you make to imported configuration via the Interplay UI are treated as overrides of the underlying 'truth' - the config received from the code repo. These overrides are preserved and re-applied to future imports unless the same setting is later changed in the code, in which case "code change wins" and the UI override is discarded.

For more details about editing components and tokens you have imported into your project, see

2. Curating from your repo

An alternative approach to curating imported items is to update the generated configuration before it gets to Interplay - effectively sending a different 'truth' to Interplay about what your repo looks like.

We make these modifications in a way that is applied every run of the import, e.g. by:

  • Programmatically modifying the config during parsing events
  • Using JSDoc tags to annotate component properties
  • Using data-attributes in JSX to modify presets (previously called examples)

Applying these modifications each run means we can still run the import repeatedly to keep Interplay up to date over time.

For more details about these options, please see:

Controlling generated config

3. Providing your own configuration

The Interplay configuration is simply a JSON config file that matches the Interplay Schema. This schema describes:

  • Components and their props in your build
  • Design tokens
  • Component presets
  • Includes - URLs that must be included to run your components, such as your deployed build files

Usually you can generate this config using the Interplay CLI, but you can instead generate your own JSON configuration file matching this schema.

We still recommend using the Interplay CLI to deploy your generated configuration to Interplay because it will authenticate to your project, validate your config and call the Interplay API to deploy. It can also be used in your CI process to automatically keep Interplay updated.

We will be posting more details about the Interplay Schema very soon - please contact us if we can help with your configuration.