Stacks

Stacks is Stack Overflow’s design system. It includes the resources needed to create consistent, predictable interfaces and workflows that conform to Stack Overflow’s principles, design language, and best practices.

Our documentation is built with Stacks itself, using its immutable, atomic classes and components.

The Stacks website documents:

Product

• Semantic and accessible component markup
• Cross-browser compatible Less / CSS
• An icon library

Email

• Email templates & components

Stacks documentation can be found at https://stackoverflow.design/

Table of contents

• Using Stacks
• Migrating from v1 to v2
• Building Stacks
• Format Stacks
• Linting Stacks
• Testing Stacks
• Releasing Stacks
• Bugs and feature requests
• Contributing
• License

Using Stacks

Using Stacks is outlined in our usage guidelines.

Migrating from v1 to v2

To migrate from Stacks v1 to v2, see our migration guide.

Building Stacks

To contribute to Stacks documentation or its CSS library, you’ll need to build Stacks locally. View our building guidelines.

Having trouble getting these steps to work? Open an issue with a setup label.

Format Stacks

Format the source code with prettier via running:

npm run format

Linting Stacks

Run all lint suites by running:

npm run lint

Lint the styles (stylelint) by running:

npm run lint:css

Lint the typescript source code (eslint) via running:

npm run lint:ts

Lint the source code format (prettier) via running:

npm run lint:format

Testing Stacks

Run all test suites by running:

npm test

Unit/Component Tests

Unit/Component tests are written with DOM Testing Library. Please follow the library's principles and documentation to write tests.

Stacks uses Web Test Runner and Playwright to run tests in a real browser context.

Execute the unit/component tests suite by running:

npm run test:unit

or if you prefer watch mode run:

npm run test:unit:watch

Visual Regression Tests

Prerequisites:

• git lfs (installation docs)
• docker (installation docs)
• pwsh (Installation docs)
• Run git config diff.lfs.textconv cat to make sure image diff works as expected (More info)

This Web Test Runner plugin is used to run visual regression tests. Visual regression tests end with this suffix *.visual.test.ts.

Execute the visual regression tests suite by running:

npm run test:visual

After the first run, if there are failing snapshots, they end up overriding the baseline ones in the filesystem (e.g. /screenshots/<browser>/baseline/<name>.png). We do this for easier comparison of the dif directly in vscode and to make sure only the failing snapshots get regenerated (see this GH discussion that inspired the approach).

We also recommend to install this vscode extension for getting better diffs.

Less Tests

This is an experimental suite to test the generation of CSS from Less files. Less tests end with this suffix *.less.test.ts.

Execute the less tests suite by running:

npm run test:less

Update the css snapshots via:

npm run test:less:update

Releasing a new version of Stacks

Stacks uses Semantic Versioning, is distributed via npm, and publishes release notes on Github.

We use changesets to automatize the steps necessary to publish to NPM, create GH releases and a changelog.

• Every time you do work that requires a new release to be published, add a changesets entry by running npx chageset and follow the instrcutions on screen. (changes that do not require a new release - e.g. changing a test file - don't need a changeset).
  • When opening a PR without a corresponding changeset the changesets-bot will remind you to do so. It generally makes sense to have one changeset for PR (if the PR changes do not require a new release to be published the bot message can be safely ignored)
• The release github workflow continuosly check if there are new pending changesets in the main branch, if there are it creates a GH PR (chore(release) see example) and continue updating it as more changesets are potentially pushed/merged to the main branch.
• When we are ready to cut a release we need to simply merge the chore(release) PR back to main and the release github workflow will take care of publishing the changes to NPM and create a GH release for us. The chore(release) PR also give us an opportunity to adjust the automatically generated changelog when necessary (the entry in the changelog file is also what will end up in the GH release notes).

The release github workflow only run if the CI workflow (running linter, formatter and tests) is successful: CI is blocking accidental releases.

Despite using changesets to communicate the intent of creating releases in a more explicit way, we still follow conventional commits standards for keeping our git history easily parseable by the human eye.

Successful releases trigger automatically a new deployment to stackoverflow.design by merging the develop branch into the production branch.

Bugs and feature requests

Have a bug or feature request? First search existing or closed issues to make sure the issue hasn’t been noted yet. If not, review our issue guidelines for submitting a bug report or feature request.

Contributing

If you’d like to contribute to Stacks, please read through our contribution guidelines. Included are directions for opening issues, coding standards, and notes on development.

License

Code and documentation copyright 2017-2024 Stack Exchange, Inc and released under the MIT License.