# @bliss-design-system/workbench

> This repository is a CLI tool for constructing different aspects of the Bliss Design System toolkits and components.

Latest version **1.4.4** (published 2021-05-06) · MIT license · 0 weekly downloads

> **Deprecated.** This package is deprecated.

## Install

```sh
npm install @bliss-design-system/workbench
pnpm add @bliss-design-system/workbench
yarn add @bliss-design-system/workbench
bun add @bliss-design-system/workbench
```

Provides the command `workbench`.

## Health

**Score 10/100 (F)** — status: deprecated.

Negative: deprecated.

## Facts

| | |
|---|---|
| Version | 1.4.4 |
| Published | 2021-05-06 |
| First published | 2021-02-19 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 9 |
| Unpacked size | 40.1 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Maintainers | carolstran, gvonkoss, coolcut, bryter-bliss |

## Links

- npm: https://www.npmjs.com/package/@bliss-design-system/workbench
- npm.io page: https://npm.io/package/@bliss-design-system/workbench

## Dependencies (9)

- [ora](https://npm.io/package/ora.md) ^5.3.0
- [gulp](https://npm.io/package/gulp.md) ^4.0.2
- [sass](https://npm.io/package/sass.md) ^1.32.8
- [chalk](https://npm.io/package/chalk.md) ^4.1.0
- [inquirer](https://npm.io/package/inquirer.md) ^7.3.3
- [commander](https://npm.io/package/commander.md) ^7.1.0
- [gulp-sass](https://npm.io/package/gulp-sass.md) ^4.1.0
- [gulp-wrap](https://npm.io/package/gulp-wrap.md) ^0.15.0
- [gulp-rename](https://npm.io/package/gulp-rename.md) ^2.0.0

## Recent versions

- 1.4.4 (latest) — 2021-05-06
- 1.4.3 — 2021-03-17
- 1.4.2 — 2021-03-11
- 1.4.1 — 2021-03-05
- 1.4.0 — 2021-03-05
- 1.3.2 — 2021-03-04
- 1.3.1 — 2021-03-04
- 1.3.0 — 2021-03-04
- 1.2.0 — 2021-02-25
- 1.1.1 — 2021-02-24
- 1.1.0 — 2021-02-24
- 1.0.5 — 2021-02-23
- 1.0.4 — 2021-02-22
- 1.0.3 — 2021-02-22
- 1.0.2 — 2021-02-22
- … 2 more at https://npm.io/package/@bliss-design-system/workbench/versions

## README

# Bliss Workbench Toolkit

This repository is a CLI tool for constructing different aspects of the Bliss Design System toolkits and components.

- [Installation](#-installation)
- [Usage](#-usage)
- [Structure](#-structure)
- [Contributing](#-contributing)
    - [Reporting a bug](#reporting-a-bug)
    - [Testing locally](#testing-locally)
    - [Committing](#committing)
    - [Opening a merge request](#opening-a-merge-request)
- [Troubleshooting](#-troubleshooting)

## 📦 Installation

To use the workbench, install the package in the root of your Bliss toolkit:

```bash
yarn add -D @bliss-design-system/workbench
```

## 🏎 Usage 

The workbench has a few commands that should be run as a command under a `package.json` script.

### Component Commands

The `workbench component` command houses two further commands; `boilerplate` and `styles`.

#### `workbench component boilerplate`

This command will initialise a boilerplate folder structure for a new component, and should only be used within the [Component toolkit](https://gitlab.com/bliss-design-system/components/).

The full command is:
```bash
workbench component boilerplate
```
But you can call
```
yarn boilerplate
```
Within the component toolkit root, and you'll be lead through a series of prompts to name your component and confirm the folder structure that will be built. This command must be called in the root of the toolkit, and all new components will be added to the `packages/` directory.

#### `workbench component styles`

Given the decisions that have  been made around Bliss' construction of web components, we've opted not to use bundlers and be as minimalistic as possible. However, because we rely on Sass for our styling (see the [Tokens toolkit](https://gitlab.com/bliss-design-system/tokens/)), we need to transpile that into CSS. But since `lit-element`, the tool we rely on to create web components, doesn't understand CSS, we also need to convert that CSS into a file our component can use. 

All style commands must be run inside the package you are working on (e.g. `packages/button`), and that package requires a `src/styles/index.scss` file to be compatible with `workbench`.

ℹ️ _Note: if you have initialised your component with `workbench component boilerplate` (which you should!), `src/styles/index.scss` will have been created for you, along with `src/styles/index.css` and `src/styles/index.css.ts`._

To generate the CSS from the SCSS and the `*.css.ts` from the CSS run:
```
workbench component styles
```
You can run the build command in watch mode (`-w` or `--watch`) to have all of your files updates as you write Sass.

## 🫕 Contributing

This toolkit is intended mostly for the Bliss team, but if you find that you use it and would like to contribute, please [open an issue](https://gitlab.com/bliss-design-system/tokens/-/issues) with your suggested change. This issue will automatically be added to the [Bliss Proposal Board](https://gitlab.com/groups/bliss-design-system/-/boards). Once that is accepted, either the Bliss team will work on it or you can make changes locally.

If you would like to contribute, run the following:

```bash
# Clone and move into this repository
git clone https://gitlab.com/bliss-design-system/workbench.git
cd workbench

# Install the dependencies
yarn
```

### Reporting a bug

Notice something off? Please [open an issue](https://gitlab.com/bliss-design-system/workbench/-/issues) using our `Bug Report` template and fill in as many details as possible.

### Testing locally

Because the workbench contains CLI scripts, you need to run it in a node environment to test it locally.

To launch your node environment, run `node` along with a path to the entry file:

```javascript
node path/to/workbench/commands/workbench.js
```

Then, you can follow that with any of the workbench commands you'd like to test. 

For example, to test the `workbench component boilerplate` script, create an empty directory called `packages` and then run the following:

```javascript
node path/to/workbench/commands/workbench.js component boilerplate
```

### Committing

We follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/), meaning that you'll be prompted to fill out a descriptive message when you commit. We also use these commits to manage our releases, so we appreciate details.

As a guideline for this toolkit, we recommend the following:
- If you are **correcting a bug in a command**, this qualifies as a patch version (`fix`)
- If you are **adding new command**, this qualifies as a minor version (`feat`)

⚠️ If you are **removing** or **renaming** a command, please speak with the Bliss team, as this will qualify as a major version and involves a breaking change.

### Opening a merge request

When you're ready to open a merge request, please use a descriptive title and fill out the provided template.

The team will be notified, but it helps to post your merge request in [#bliss_support](https://bryterworkspace.slack.com/archives/CLBTUEQ5P).

## 🙃 Troubleshooting

We'll fill this section out as we go and as issues are raised. But if you haven't found what you're looking for, get in touch via [bliss@bryter.io](mailto:bliss@bryter.io) or via the [#bliss_support](https://bryterworkspace.slack.com/archives/CLBTUEQ5P) Slack channel ✨.

---
_Source: https://npm.io/package/@bliss-design-system/workbench · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._
