@brightspace-ui-labs/caketray

@brightspace-ui-labs/secondary-card

Note: this is a "labs" component. While functional, these tasks are prerequisites to promotion to BrightspaceUI "official" status:

• Design organization buy-in
• design.d2l entry
• Architectural sign-off
• Continuous integration
• Cross-browser testing
• Unit tests (if applicable)
• Accessibility tests
• Visual diff tests
• Localization with Serge (if applicable)
• Demo page
• README documentation

A card for use with the secondary pane in the primary-secondary template

Installation

Install from NPM:

npm install @brightspace-ui-labs/secondary-card

Usage

<script type="module">
    import '@brightspace-ui-labs/secondary-card/secondary-card.js';
</script>
<d2l-labs-secondary-card title-text="This is a title">
	<slot name="card-content">This is the contents of the card.</slot>
</d2l-labs-secondary-card>

Properties:

Property	Type	Description
title-text	String	text appears as the header of the component
summary-text	String	text appears as summary when card is closed. No effect if component is not collapsable.
collapsable	Boolean	when true, the card is collapsable using the d2l-labs-accordion

Accessibility:

To make your usage of d2l-labs-secondary-card accessible, use the following properties when applicable:

Attribute	Description

Developing, Testing and Contributing

After cloning the repo, run npm install to install dependencies.

Linting

# eslint and lit-analyzer
npm run lint

# eslint only
npm run lint:eslint

Testing

# lint & run headless unit tests
npm test

# unit tests only
npm run test:headless

# debug or run a subset of local unit tests
# then navigate to `http://localhost:9876/debug.html`
npm run test:headless:watch

Running the demos

To start an es-dev-server that hosts the demo page and tests:

npm start

Versioning & Releasing

TL;DR: Commits prefixed with fix: and feat: will trigger patch and minor releases when merged to master. Read on for more details...

The sematic-release GitHub Action is called from the release.yml GitHub Action workflow to handle version changes and releasing.

Version Changes

All version changes should obey semantic versioning rules:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

The next version number will be determined from the commit messages since the previous release. Our semantic-release configuration uses the Angular convention when analyzing commits:

• Commits which are prefixed with fix: or perf: will trigger a patch release. Example: fix: validate input before using
• Commits which are prefixed with feat: will trigger a minor release. Example: feat: add toggle() method
• To trigger a MAJOR release, include BREAKING CHANGE: with a space or two newlines in the footer of the commit message
• Other suggested prefixes which will NOT trigger a release: build:, ci:, docs:, style:, refactor: and test:. Example: docs: adding README for new component

To revert a change, add the revert: prefix to the original commit message. This will cause the reverted change to be omitted from the release notes. Example: revert: fix: validate input before using.

Releases

When a release is triggered, it will:

• Update the version in package.json
• Tag the commit
• Create a GitHub release (including release notes)
• Deploy a new package to NPM

Releasing from Maintenance Branches

Occasionally you'll want to backport a feature or bug fix to an older release. semantic-release refers to these as maintenance branches.

Maintenance branch names should be of the form: +([0-9])?(.{+([0-9]),x}).x.

Regular expressions are complicated, but this essentially means branch names should look like:

• 1.15.x for patch releases on top of the 1.15 release (after version 1.16 exists)
• 2.x for feature releases on top of the 2 release (after version 3 exists)