@hashicorp/mktg-global-styles

Global Styles

Global styles used across HashiCorp sites.

The Rundown

The primary import is style.css, which contains a few important styles:

• a css normalize (src)
• a range of custom media queries (src)
• all of our standard fonts (src)
• a range of css custom properties covering brand colors (src)
• a range of css custom properties covering standard font stacks (src)
• a number of classes for applying type styles (src)
• the .g-grid class which is our standard grid layout setup (src)
• the .g-grid-container class which is our standard content container (src)

Each of these can be imported individually, but this is not recommended. They are separated for internal organization rather than external consumption

Work Needed

This package is severely out of date and generally needs a lot of additional work, most of which will be breaking. A short list of what needs to change follows:

• code-highlighting.css is no longer used, instead code highlighting styles are imported from @hashicorp/nextjs-scripts
• all of the temporary-to-remove files need to be evaluated and culled
• several files have cross-referenced css imports, which are not necessary. for example, since global imports our color variables, it does not need to be imported in any other file, or it will be doubled. these imports are relics from when we compiled variables rather than using them as-is
• the global file needs to be broken apart into pieces and assembled within style.css

Publishing

Publishing is handled through the changesets library. Publishing is done in CI if changes are found. For more information on how to work with changesets, see this document.

Adding a changeset

Run the following command and follow the prompt:

npx changeset

To make any adjustments to your changeset, just edit the file!

Releases

The release process is handled mostly automatically via the changesets GitHub action. When changeset files get merged to main, a Pull Request is opened which will, upon merge, release all pending changesets and remove the changeset files. We should not need to publish manually with this flow. See the changesets/action(https://github.com/changesets/action) repo for more information.

Canary Releases

If you want to test your changes before merging, you can add a release:canary label to your pull request. If any changeset files are found, a release will be created and tagged with canary. You can then install the canary version elsewhere:

npm install @hashicorp/mktg-global-styles@canary

Prereleases

Prereleases are also handled through a process integrated into changesets. The full flow is outlined in this document. To enter a prerelease mode for the canary tag, we would do something like this:

npx changeset pre enter canary
GITHUB_TOKEN=<your token> npx changeset version
GITHUB_TOKEN=<your token> npx changeset publish

To continue publishing preleases, use the npx changeset command like normal and use the version and publish commands as appropriate.