Workflow and use-cases

[JayaKrishnaNamburu]

This issue is to list out the possible way the cli can help in enabling project deployments and working in general

Expectation

As a user, one should be able to download a project from webstudio using a command line tool and deploy the generated build to any desired hosting provider. (Although if the cli is capable enough to deploy that would be great. But that can be a little out of scope at the moment. As it needs cli to have implementations with all possible providers. Eg: Or a leat wrap the existing one like vercel to deploy them)

Stages

With the requirement, we should ideally able to complete this whole process with a series of commands. Like

init / login

webstudio init <share-url>

The current approach is to load a project and save the apiKey in the config path. So the subsequent usage of sync and build can just use the API keys from the config. This is the current implementation too.

build

webstudio build <project-id>

When ran, should create a new project and load the data of the project and build it at the same time. During build time, the templates are being copied from the local path to the BUILD_DIR here. Here is the place that needs improvement.

• First, the cli's are usually installed globally. So, the same with this use-case too. So, we can't run cp ./ with relative paths. As the templates are not bundled with the current setup as it is. There are multiple things that can be considered to solve this.

1. We can save the templates as a JSON file. That stores the file name and content as key-value pairs. These JSON's can be parsed and populated into the BUILD_DIR using fs.
2. The first approach looses syntax highlighting when maintaining, so the approach will be to bundle these files as those JSON's at the build time and maintain them. But it's too much of a setup things, and slows down in dev iteration.
3. Save all the templates in a new project in GitHub. We can use something like this and load all the files from the github using commitId. Just in case if the cli want to be safe of the future template updates. It helps in syntax highlighting, no relative path issues and makes the cli lightweight by not bundling all of them into it.

sync

webstudio sync

The command sync can be ran inside a existing webstudio project. So, there is no need to pass the projectId once again. This can be picked from app/app.json where the data is stored when the project is built for the first time. Then it fetches the new content from the project and runs the build once again. Because sync was supposed to keep the existing project with the current state in the UI.

Example flow

• User runs webstudio init ${url} a project
• Runs webstudio build ${projectId} to build the project
• Can use webstudio sync to sync with new changes.
• Can use vercel deploy or something. inside the project to upload the built files for deployment.

[kof]

We can save the templates as a JSON file. That stores the file name and content as key-value pairs. These JSON's can be parsed and populated into the BUILD_DIR using fs.

Lets keep the templates on a file system inside the source - this way they are readable like normal code. You can turn them into template literals as a build step for the CLI, here is an example of how we do such build steps https://github.com/webstudio-is/webstudio-builder/blob/main/packages/css-data/package.json#L13

[kof]

This can be picked from app/app.json

webstudio.json

[kof]

• if build is supposed to be run only once, shouldn't this actually be part of the "init"? Is vercel, remix or any other scaffolding CLI calling it build?

[kof]

I think we can have a webstudio deploy and depending on the configured destination it will call the right script, this way you don't have to use a new command depending on the target every time.

Similar to turborepo