Plugin SDK > Releasing new plugin versions

Releasing new plugin versions

If you already have published a plugin on the DatoCMS Marketplace, here is what you need to do in order to release a new version.

Developing a new version of a published plugin

To test a new local version of a plugin that has already been published, make sure to create a new sandbox environment, then enter the "Developer zone" settings, and specify a local entry point URL for the plugin.

This way, all the settings you already entered for the plugin and all the fields where you installed its manual field extensions will remain untouched, but you'll be able to test new code.

Releasing a canary version

Following the usual NPM convention, other users will see the upgrade notification for your plugin only when a new package version is tagged as latest. This means that you can release a canary version of your plugin that only you can test by publishing it to any other NPM dist-tag.

In this example, we'll use the next tag:

npm publish --tag next

Once the new version is published, open the "Developer zone" section and click on "Upgrade to canary release". A prompt will appear asking the exact canary version you want to install.

Releasing an official new version

Once you made sure the canary release works as expected, you can publish a new version on the latest NPM tag:

npm publish

Once published, all the projects where the plugin is installed will receive a notification asking them to upgrade to the latest version:

Migrating old global plugin settings

The new version might need to store different settings than the previous ones. This can happen both for global settings, or the settings associated to a particular use of a manual extension inside a field.

If the end-user decides to upgrade to the latest version of the plugin, DatoCMS keeps the old settings saved. This means that plugins have to somehow manage configuration objects in older formats too.

Let's concentrate on global plugin settings first, ctx.plugin.attributes.parameters. We can easily build some Typescript types and type guard functions to properly describe all the possibile formats in which settings might be stored:

1
// ctx.plugin.attributes.parameters can be in one of these formats:
2
type Config = EmptyConfig | V1Config | V2Config;
3

4
// As soon as the plugin is installed, config is an empty object:
5
type EmptyConfig = {};
6

7
// Plugin v1 version saves config in this format:
8
type V1Config = {
9
  someOption: 'yes' | 'no';
10
}
11

12
// Current version changes the format for `someOption`, and adds `newOption`:
13
type V2Config = {
14
  someOption: boolean;
15
  newOption: string;
16
}
17

18
const isEmptyConfig = (parameters: Config): parameters is EmptyConfig => {
19
  return Object.keys(parameters).length === 0;
20
}
21

22
const isV1Config = (parameters: Config): parameters is V1Config => {
23
  return 'someOption' in parameters;
24
}
25

26
const isV2Config = (parameters: Config): parameters is V1Config => {
27
  return 'newOption' in parameters;
28
}

In this example, new and old config formats are somewhat compatible, so we can use the onBoot hook — which gets called as soon as the DatoCMS application loads, or the plugin is installed for the first time — to silently update the plugin configuration to the new format or, if it's the first installation for the plugin, to provide some default configuration:

1
function normalizeConfig(parameters: Config): V2Config {
2
  if (isEmptyConfig(parameters)) {
3
    return { someOption: true, newOption: 'foobar' };
4
  }
5

6
  if (isV1Config(parameters)) {
7
    return { someOption: parameters.someOption === 'yes', newOption: 'foobar' };
8
  }
9

10
  return parameters;
11
}
12

13
connect({
14
  onBoot(ctx: OnBootCtx) {
15
    if (isV2Config(ctx.plugin.attributes.parameters as Config)) {
16
      return;
17
    }
18

19
    if (ctx.currentRole.meta.final_permissions.can_edit_schema) {
20
      ctx.updatePluginParameters(
21
        normalizeConfig(ctx.plugin.attributes.parameters as Config),
22
      );
23
    }
24
  },
25
  renderPage(pageId, ctx) {
26
    const parameters = normalizeConfig(ctx.plugin.attributes.parameters as Config);
27
    // ...use the normalized config from now on
28
  },
29
});

What if new config format is not compatible with older ones?

Unfortunately, it can also happen to introduce changes in a newer version that are not backward compatible. In this case, our approach will slighly change, as we need one of the project admins to manually change the settings in the config screen:

1
connect({
2
  async onBoot(ctx: OnBootCtx) {
3
    if (isConfigValid(ctx.plugin.attributes.parameters as Config)) {
4
      return;
5
    }
6

7
    if (!ctx.currentRole.meta.final_permissions.can_edit_schema) {
8
      ctx.customToast({
9
        type: 'warning',
10
        message:
11
          'Invalid settings. Please ask your administrators to fix the issue!',
12
      });
13

14
      return;
15
    }
16

17
    const result = await ctx.customToast({
18
      type: 'warning',
19
      message:
20
        'Invalid settings. Please fix them to make the plugin work again!',
21
      cta: {
22
        label: 'Go to plugin settings',
23
        value: 'settings',
24
      },
25
    });
26

27
    if (result === 'settings') {
28
      ctx.navigateTo(`/admin/plugins/${ctx.plugin.id}/edit`);
29
    }
30
  },
31
  renderPage(pageId, ctx) {
32
    // fast return
33
    if (!isConfigValid(ctx.plugin.attributes.parameters as Config)) {
34
      return <div>Functionality disabled until settings are fixed!</div>;
35
    }
36
  },
37
});

Let's review what this code is doing:

every hook that needs to read the configuration object (renderPage in this example) can use the isConfigValid() function to test if it can execute normally, or it needs to fast return to avoid errors due to incompatible settings;
the onBoot hook shows a notification to the end user telling that the configuration needs to be manually fixed, or the plugin won't work.

Migrating old manual Field Extension settings

A very similar approach can also be used to handle changes in manual field extension settings between versions.

If the new configuration is compatible with the old one:

the renderFieldExtension hook uses a normalizeParameters() function to convert older configuration objects into the latest format;
the onBoot hook first needs to determine if it needs to do the migration: to do that, it can look into ctx.plugin.attributes.parameters and see if ie. global settings have already some flag. Then it fetches all the fields that are hooked to our plugin using ctx.loadFieldsUsingPlugin(), and for each of them it uses the ctx.updateFieldAppearance() function to silently update the field extension to the new format.

1
connect({
2
  async onBoot(ctx: OnBootCtx) {
3
    if (
4
      ctx.plugin.attributes.parameters.version !== '2' ||
5
      !ctx.currentRole.meta.final_permissions.can_edit_schema
6
    ) {
7
      return;
8
    }
9

10
    const fields = await ctx.loadFieldsUsingPlugin();
11

12
    await Promise.all(
13
      fields.map(async (field) => {
14
        const { appearance } = field.attributes;
15
        const changes: FieldAppearanceChange[] = [];
16

17
        if (
18
          appearance.editor === ctx.plugin.id &&
19
          appearance.field_extension === 'oldFieldEditorName'
20
        ) {
21
          changes.push({
22
            operation: 'updateEditor',
23
            newFieldExtensionId: 'newFieldEditorName',
24
            newFieldExtensionParameters: normalizeConfig(appearance.parameters),
25
          });
26
        }
27

28
        if (changes.length > 0) {
29
          await ctx.updateFieldAppearance(field.id, changes);
30
        }
31
      }),
32
    );
33
  },
34
  renderFieldExtension(fieldExtensionId, ctx) {
35
    const parameters = normalizeConfig(ctx.parameters);
36
    // ...use the normalized config from now on
37
  },
38
});

If old versions and new versions are incompatible, just like with the global settings before, all we can do is warning the user that manual field extensions need to be manually reconfigured. The Config screen can then offer some kind of UI to help users migrate manual field extensions in batch by providing some options:

1
connect({
2
  async onBoot(ctx: OnBootCtx) {
3
    if (ctx.plugin.attributes.parameters.version === '2') {
4
      return;
5
    }
6

7
    if (!ctx.currentRole.meta.final_permissions.can_edit_schema) {
8
      ctx.customToast({
9
        type: 'warning',
10
        message:
11
          'Invalid settings. Please ask your administrators to fix the issue!',
12
      });
13

14
      return;
15
    }
16

17
    const result = await ctx.customToast({
18
      type: 'warning',
19
      message:
20
        'Invalid settings. Please fix them to make the plugin work again!',
21
      cta: {
22
        label: 'Go to plugin settings',
23
        value: 'settings',
24
      },
25
    });
26

27
    if (result === 'settings') {
28
      ctx.navigateTo(`/admin/plugins/${ctx.plugin.id}/edit`);
29
    }
30
  },
31
  renderFieldExtension(fieldExtensionId, ctx) {
32
    if (ctx.plugin.attributes.parameters.version !== '2') {
33
      return <div>Functionality disabled until settings are fixed!</div>;
34
    }
35

36
    // ...
37
  },
38
});

Did this doc help you?

Need help?

Explore our forum, contact support, or connect with our sales team . You can also chat live with other users in our Slack channel.