npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@phase2/sic-tokens

v0.0.10

Published

Design Token Library: The Standard

Downloads

1

Readme

Design Token Library

This is a source of truth for design tokens for The Standard.

Developer Workflow

Basic workflow for token management and updating.

Installation

git clone [email protected]:phase2/sic-tokens.git
cd sic-tokens
yarn install

Updating Tokens

  • Update appropriate tokens in the tokens/SET directory.
    • Initially, only the tokens/default set is included.
    • Tokens are split into multiple files. The files are numbered simply to demonstrate the cascade order we define.
      • 01-global.json
      • 02-alias.json
      • 03-component.json
  • Ensure npm scripts are correct for any sets being processed and published.
    • The scripts are intentionally hard coded to process the tokens/default directory only. If more theme sets are added, the NPM scripts in package.json will need to be adjusted accordingly.

Building Token Definitions

yarn build

Scripts

  • yarn build:token-transformer:default - Runs the token-transformer library against the tokens/default directory with the following flags, creating an output file at dist/tokens.default.json.
    • --expandTypography=true
    • --expandShadow=true
    • --expandComposition=true
  • yarn build:style-dictionary - Runs the style-dictionary library against any outputs defined in config.json.

Releases

By default, the system is set up for a manual release process. An account on npmjs.com authorized to publish to the @phase2 namespace.

  • Commit or pull changes
    • feat(release): Release version X.X.X.
  • npm login
  • Update version number in package.json
  • yarn package

Integration

The following describes how to integrate the token library into your application.

.npmrc

Applications consuming the Design Token Library may need an .npmrc file with the following information:

@phase2:registry=https://registry.npmjs.org

Primary Dependencies & Tooling

Samples

The following samples are included in the primary repository to demonstrate basic usage of the tooling.

Simple

The samples/simple directory contains the most basic implementation to demonstrate the usage of the design token library. To test out the system, the following steps should work:

Workflow

  • Ensure you have a proper token setup as described in the Access Token section above.
  • cd samples/simple
  • npm install - Ensure everything installs with zero errors.
  • npx serve . - Creates a localhost server to demonstrate working implementation of tokens from @phase2/sic-tokens package.

Files of note

The following files show various portions of the implementation.

  • samples/simple/index.html - Basic markup and inclusion of various CSS files.
  • samples/simple/node_modules/@phase2/sic-tokens/dist/tokens.default.css - The generated tokens file from the @phase2/sic-tokens package.
  • samples/simple/styles.css - Basic CSS using standard CSS as well as integrating variables from tokens.default.css.

Caveats

What this samples/simple demo does NOT show is the process that must be included to properly rsync the tokens.default.css file from node_modules to a location more suited for the application implementing the package. This could be done via a postinstall / postupdate script or multiple other means.

Semantic Versioning

This feature is currently not tied into an automated release process.

In order that the design token library can maintain semantic versioning, and provide stable releases to various applications, this system is set to use Conventional Commits via commitlint and husky.

Conventional Commits

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit messages are in the form: type(tag): message.

Types include

  • fix: Fix - (this correlates with PATCH release in Semantic Versioning)
  • feat: Feature - (this correlates with MINOR release in Semantic Versioning)
  • BREAKING CHANGE: A commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (this correlates with a MAJOR release in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
  • chore or something else: Ignored

When code is merged, tooling will create a new package version with the major.feature.fix semantic versioning.

For example, if you add a few commit messages:

  • feat(colors): Updated the colors for the base set.
  • feat: Updated configuration for a thing to be better.
  • fix: Fixed the first thing I did.

If you had a version 1.2.3, this would create a new version 1.3.0 since there is a new feature. It only increments once even though there are multiple commits.

See the examples for more usage information.

@todo

  • Finalize token naming structure in all systems.
  • Ensure exports coming from Token Studio are as expected and/or desired.