marnocha/coveo-ui-kit

Coveo UI kit repository, home of @coveo/headless, @coveo/atomic, and more.

Coveo UI Kit

Projects

• Headless: Stateful middle-layer between UI elements and the Coveo Platform.
• Atomic: Coveo's web-component library for building modern search experiences.
• Quantic: Coveo's LWC library for building Salesforce search experiences.
• Bueno: A simple schema validator.
• Auth: Functions to help authenticate with the Coveo platform.
• Headless React Samples: Various code samples using Headless inside a React application.

Installation

To install all dependencies and link local packages, run:

npm i

To install a dependency in a specific package, specify the workspace:

npm i lodash -w @coveo/headless-react-samples

To build all projects for production, run:

npm run build

To build a single project for production (for instance, the @coveo/atomic package), run:

npm run build -w @coveo/atomic

To start a single project in development (for instance, the quantic package), run:

npm start -w @coveo/quantic

To start Atomic & Headless simultaneously in development (recommended), run:

npm run dev

The project uses git hooks with Husky. You can make sure hooks are correctly installed using the npm rebuild command.

The following Visual Studio Code extensions are recommended:

• ESLint
• Prettier

Prerelease

To start a major prerelease (e.g., 1.2.3 → 2.0.0-pre.0)

1. Make sure that HEAD refers to a version bump on master.
2. Create a new branch prefixed with prerelease/ (e.g., prerelease/headless_atomic_v2).
3. Run npm run bump:version:major-prerelease -- @coveo/package1 @coveo/package2 @coveo/package3.
4. Push the new commit and its tags to the branch.

Adding a new package to an already started prerelease

1. Checkout the prerelease branch.
2. Run npm run bump:version:major-prerelease -- @coveo/package1 where @coveo/package1 is the new package.
3. Push the new commit and its tags to the branch.

Updating a prerelease branch

1. Wait for master to reference a version bump.
2. Pull changes from master into the prerelease branch.

Officially releasing (e.g., 2.0.0-pre.15 → 2.0.0)

1. Create a pull request from a copy of the prerelease branch to “master”.
   • Associate with a Jira issue which QA will use to validate.
   • Update the changelogs manually, adding all the changes from the last release to the new release.
   • Update all dependents to use the prerelease version (include the -pre. suffix).
2. Wait for master to reference a version bump.
3. Squash as a version bump.
   • You can copy the title & description of the last version bump commit on the prerelease branch.
   • You must add the link to the Jira issue at the beginning of the description.