Plugins
Buildprint pode funcionar com plugins do Bubble, não apenas com apps. Um plugin é seu próprio tipo de projeto: você o clona para um workspace local, edita os arquivos triturados como código, envia os arquivos de assets compilados, salva o rascunho no Bubble com buildprint apply e então repassa o rascunho ao proprietário do plugin para publicar uma versão no editor do Bubble.
Tudo nesta página passa pelo grupo de comandos plugin:
buildprint plugin clone <pluginId>
buildprint plugin upload ./dist/widget.js
buildprint plugin publish -m "Release notes" --patch
buildprint plugin versionsPré-requisitos
Você precisa estar autenticado e vinculado.
Você precisa do ID do plugin no Bubble. Este é o ID que o Bubble usa para o plugin na URL do editor (
https://bubble.io/plugin_editor?id=<pluginId>). Ele também pode ser encontrado combuildprint project list --json.
Clonar um plugin
buildprint plugin clone <pluginId>
buildprint plugin clone <pluginId> --dir ./my-pluginclone busca o rascunho atual do plugin no Bubble, o tritura em uma árvore do sistema de arquivos e inicializa um workspace local do plugin.
<pluginId>(obrigatório) - o ID do plugin no Bubble a ser clonado.--dir <path>- substitui o diretório raiz do plugin. O padrão é<pluginId>.
O diretório de destino precisa estar vazio (ou ainda não existir). Se o diretório já for um workspace de app do Buildprint, ou já for um workspace de um plugin diferente, o clone é interrompido e você recebe a orientação para usar --dir para clonar em outro lugar.
Layout do workspace
A raiz de um plugin é um workspace do Buildprint assim como a raiz de um app: ela contém a configuração .buildprint/ e o repositório git vazio, e os arquivos editáveis ficam em uma única worktree irmã chamada plugin:
<plugin-root>/
.buildprint/ # workspace config and bare Bubble repo
plugin/ # the editable plugin worktree
plugin.json # top-level plugin scalars (includes editor_counter)
meta.json # plugin metadata (name, description, license, ...)
elements/ # plugin element definitions
actions/ # plugin action definitions
api/ # plugin API calls
assets.json # uploaded asset references (see upload)refs/bubble/plugin acompanha o último snapshot sincronizado do Bubble e refs/published/plugin acompanha o último commit aplicado ao Bubble, espelhando o modelo de branch do app.
Depois de um clone bem-sucedido, use cd para entrar na worktree plugin/ e trabalhar:
cd <plugin-root>/pluginEditar e verificar
Edite os arquivos triturados como código e, depois, valide antes de aplicar:
buildprint checkcheck entende o tipo de workspace de plugin e executa o conjunto de regras do plugin (incluindo verificações de prontidão para publicação). Se mudanças no editor do Bubble aconteceram fora do fluxo normal, puxe-as com buildprint sync antes de continuar - edições diretas no editor ficam invisíveis até você ressicronizar e serão sobrescritas pela próxima aplicação.
Enviar um asset
buildprint plugin upload ./dist/widget.js
buildprint plugin upload ./logo.svg --name "logo.svg" --type image/svg+xmlupload envia um único arquivo local ao Bubble como um asset do plugin e registra uma referência a ele em assets.json. Execute-o de dentro da worktree do plugin.
<file>(obrigatório) - o arquivo local a ser enviado.--name <asset name>- o nome do asset a ser armazenado emassets.json. O padrão é o nome base do arquivo enviado. Deve ser um nome de arquivo simples, não um caminho.--type <mime>- o tipo MIME a ser enviado ao Bubble. Se omitido, ele é inferido pela extensão do arquivo, com fallback paraapplication/octet-stream.
Antes de enviar, o comando formata o JSON alterado, executa as verificações do plugin e confirma que a base local está atualizada em relação ao Bubble. O arquivo deve existir, não pode estar vazio e deve ter menos de 5 MB. A chave do asset gerada é um espaço reservado new_<slug> derivado do nome do asset; se assets.json já contiver essa chave, escolha um --name diferente.
O upload registra o asset apenas localmente. Para realmente salvá-lo no rascunho do plugin no Bubble, aplique suas alterações:
buildprint applySe o Bubble informar divergência (plugin_drift), execute buildprint sync e tente novamente.
Salvar rascunho vs publicar
Os dois estados são distintos, e isso importa:
Salvar rascunho -
buildprint applycompila suas edições locais (alterações de elementos/ações/API, assets enviados) em mudanças Bubble/writee as salva no rascunho do plugin. Isso é tudo o que o apply faz para plugins.Publicar uma versão - uma etapa separada e explícita. O Bubble só permite que o proprietário do plugin envie uma nova versão publicada a partir do editor do plugin, então
buildprint plugin publishnão publica por você. Ele valida se o rascunho está pronto e imprime as instruções exatas de repasse ao proprietário (link do editor e mensagem de release).
Preparar uma publicação
buildprint plugin publish -m "Release notes"
buildprint plugin publish -m "Fix rendering bug" --patch
buildprint plugin publish -m "Generate owner handoff despite warnings" --forceExecute de dentro da worktree do plugin. publish verifica a prontidão e depois imprime as instruções para o proprietário do plugin enviar uma nova versão no editor do Bubble.
-m, --description <description>(obrigatório) - a descrição/mensagem da release. Deve ter 120 caracteres ou menos.--major- prepara uma versão major.--minor- prepara uma versão minor.--patch- prepara uma versão patch.--force- imprime o repasse ao proprietário mesmo quando houver avisos de prontidão para publicação. O Bubble pode modificar ou rejeitar o plugin.
Escolha no máximo um entre --major, --minor ou --patch. Se o plugin já tiver uma versão publicada, um tipo de atualização é obrigatório; para a primeira publicação de um plugin, o tipo é opcional.
publish se recusa a executar se a worktree tiver alterações não commitadas ou não aplicadas - aplique primeiro com buildprint apply. Ele também se recusa se as verificações do plugin reportarem erros e, a menos que use --force, se houver avisos de prontidão para publicação. Em caso de sucesso, ele imprime o link do editor do plugin (https://bubble.io/plugin_editor?id=<pluginId>&tab=tabs-6) e os passos para o proprietário: abrir o editor, clicar em "Submit a new version", escolher o tipo de release e colar sua mensagem de release. Nenhuma versão pode ser publicada pela própria CLI.