Feature Branches

Sygnal's preferred approach is to branch feature development to keep main clean and allow for freedom of experimentation and Webflow designer testing.

Typically we name our feature branches using the convention feature/NAME.

Creating a Feature Branch

Create your new feature branch, e.g.;

git checkout -b feature/NAME

Working with a Feature Branch

In VSCode, you'll see the currently selected branch in the bottom-left corner;

Designer-Testing a Feature Branch

First, verify you're on the correct feature branch.

npm run deploy

Will deploy the lib to your designated workspace, but as a Test version;

• The Library name will end in Test

• The Library ID with a -test suffix

Sygnal's deployment setup is branch-aware and distinguishes between main and non-main branches. Any deployment of a non-main branch will be handled as a Test lib. In this setup, you can have only one Test lib at a time, so if you're developing multiple features, you can integration one at a time.

In the designer, you'll see your library as e.g. My Library Test v1.0.0 ⚠️

Install or update that library in your test project.

Add any components you want- it will

Merging a Feature Branch into Main

This outlines the basic process; make sure that if you're working in a team, that you use git pull origin to update your local copy.

In general we want to keep feature branches clean- so that they only contain the new component(s) you're building or refactoring.

Advanced Merge Notes

If you've made extensive changes that could create conflicts look into git cherry-pick .

Start from your feature branch, e.g.

git checkout feature/NAME

Make sure everything is committed;

git status

See commits that aren't on main;

git log --oneline main..feature/rive

See which files have changed;

git log --oneline main..feature/rive

Examine detailed file changes if you want;

git diff --stat main..feature/rive 

Switch to the main branch;

git checkout main

Merging

In most cases we prefer to preserve branch history.

Replace NAME with the actual feature name.

From the main branch,

Update the version number in src/version.ts

Perform the feature branch merge, e.g.;

git merge --no-ff -m "Merge feature into main" feature/NAME

Then, usually cleanup by removing the feature branch;

git branch -d feature/NAME 

Some alternative merging approaches

You may also be able to fast-forward merge;

git merge feature/NAME

Or squash merge ( combine all commits into one );

e.g.;

git merge --squash feature/NAME
git commit -m "Add new component"

Final Integration Review

With the feature now merged into main, retest to ensure the integration was successful.

Update the version.ts to reflect the new library version. This will be important for marketplace users, and for multiple-workspace distributions.

Deploy main to your testing workspace.

npm run deploy

From main, this will deploy the library under its proper name, without the Test suffix.

Retest.

In the designer, accept the library revisions from the library panel.

• Replace your Test library components with the production library components.

You can see both libraries, the test and the prod versions;

Important, currently there is no way to distinguish in the designer between test and production component versions, they will look identical in the left nav, and in the properties list during this replacement process.

To simplify this, select the old component, add the new one and it will position directly after. then copy-past your property settings.