feat(cli): deploy options from manifest file

[demetriusfeijoo]

What?

Deploy options found in the manifest file while creating or updating a plugin through the CLI.

Why?

JIRA: EXT-1880

This feature will enable the developer to version the plugin's options together with the source code, making it easy to maintain and revert changes.

How to test? (optional)

1. Navigate to any template (in this example the JS one)

cd packages/cli/templates/js

2. Make adjustments in the field-plugin.config.json file (manifest file)

{
    "options": [
        {
            "name": "opt1",
            "value": "val1"
        }
    ]
}

3. Create or update a field plugin with the following command

STORYBLOK_PERSONAL_ACCESS_TOKEN=[your token] npx field-plugin deploy

4. Open the generated plugin link and check if the options were sent properly

I've tested creating and updating plugins for all different kinds of scopes (my-plugins, organization, and partner-portal), I also tested with the skipPrompts parameter. However, any help on testing them would be welcomed 😄

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
plugin-sandbox	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 20, 2023 3:13pm

[demetriusfeijoo]

I'd like to have opinions about the creation of a common package, if it makes sense or not and if it would exist another better way of doing that.

Motivation:

Since the manifest.ts used in our Vite Helper would be the same as the one used in our CLI, I thought in way of sharing this script between both Vite Helper and the CLI.

What are your thoughts on that?

[BibiSebi]

I'd like to have opinions about the creation of a common package, if it makes sense or not and if it would exist another better way of doing that.

Motivation:

Since the manifest.ts used in our Vite Helper would be the same as the one used in our CLI, I thought in way of sharing this script between both Vite Helper and the CLI.

What are your thoughts on that?

Here is a brief article I read on internal packages, which would be the case for us now. I think it makes sense to have a package to share this logic, however I am not sure about the naming. Maybe we need to specify the package name more to know what is its' scope (something like manifest-helper?)

[demetriusfeijoo]

Thanks for the reference @BibiSebi 🙌

To be sincere, I enjoyed manifest-helper.

I'm going to rename it that way.

[BibiSebi]

@demetriusfeijoo what is the status of this PR? Do you need any help? :)

[demetriusfeijoo]

Hey @BibiSebi, thanks for commenting on this and also for the support.

I've updated the PR with some improvements/notes and now it's working for field plugins of any type (my-plugins, partner-portal, and organization).

However, it works only for updates, not creations since the API does not accept options during creation time (or I wasn't able to do so).

If it's true about the API not accepting options during creation time, I see only 2 paths here:

1. For every creation, also perform an update if a valid manifest file is found and if it contains options.
2. Ask the team responsible for the API to also accept options during creation. 🤣

The second approach would be the perfect one but we'd need to wait for them to make this change and it may take a long time, IDK.

What do you think about it @BibiSebi @eunjae-lee? How should we proceed on this case?

[BibiSebi]

Hey @BibiSebi, thanks for commenting on this and also for the support.

I've updated the PR with some improvements/notes and now it's working for field plugins of any type (my-plugins, partner-portal, and organization).

However, it works only for updates, not creations since the API does not accept options during creation time (or I wasn't able to do so).

If it's true about the API not accepting options during creation time, I see only 2 paths here:

1. For every creation, also perform an update if a valid manifest file is found and if it contains options.
2. Ask the team responsible for the API to also accept options during creation. 🤣

The second approach would be the perfect one but we'd need to wait for them to make this change and it may take a long time, IDK.

What do you think about it @BibiSebi @eunjae-lee? How should we proceed on this case?

To your question, let me test this behaviour. And I agree we need the api to be adapted in that case so 2. would be the better option.