TACC Core Styles
The shared styles for TACC WMA Workspace Portals & Websites
Known Clients
- Core CMS, the base CMS code for TACC WMA CMS Websites
- Core Portal, the base Portal code for TACC WMA CMS Websites
- TUP UI, the client code for TACC User Portal
Table of Contents
External Project Usage
Install This Package
-
Installwith any package manager e.g.:
npm install @tacc/core-styles
yarn add @tacc/core-styles
-
Import stylesheets of either type:
- pre-compiled, from
/dist
- source files, from
/src/lib/_imports
Build from Source
Via Your Environment's PostCSS
Please review the plugins expected.
Via Core-Styles API
JavaScript
require('core-styles').buildStylesheets
const buildStylesheets = require('core-styles').buildStylesheets;
buildStylesheets(
`path/to/your/css/src`,
`path/to/put/css/output`,
{
customConfigs: [
`path/to/custom/config/that/extends/base/.postcssrc.yml`,
`path/to/custom/config/that/extends/above/.postcssrc.yml`,
],
verbose: true,
version: true,
buildId: process.env.npm_package_version + someUniqueId,
}
);
CLI
core-styles
Usage: core-styles [options] [command]
Options:
-V, --version output the version number
-h, --help display help for command
Commands:
build [options] build stylesheets with TACC standard process:
- "post-css" plugins
- custom input path
- custom output path
- custom configs
- prepend build id
help [command] display help for command
core-styles build
Usage: core-styles build [options]
build stylesheets with TACC standard process:
- "post-css" plugins
- custom input path
- custom output path
- custom configs
- prepend build id
Options:
-i, --input <path> parse source at which path¹
-o, --output <path> output CSS files to which path¹
-v, --verbose print more info during build process
-c, --custom-configs <paths...> extend base config with YAML files²³
-b, --build-id <identifier> any value to identify the build (default: version of app)
-m, --base-mirror-dir <path> if input folder structure is mirrored, this path is not⁴
-h, --help display help for command
Notes:
¹ Folder structure of "--input-dir" mirrored in "--output-dir" i.e.
given input
- "input_dir/x.css"
- "input_dir/sub_dir_a/y.css"
- "input_dir"
- "input_dir/**/*"
expect output
- "output_dir/x.css"
- "output_dir/sub_dir_a/y.css"
- "output_dir/..." (all files from input not in sub-directories)
- "output_dir/.../..." (all files from input as nested)
² The file formats are like ".postcssrc.yml" from
https://github.com/postcss/postcss-load-config
³ The first file is merged on top of the base config.
Each successive file overwrites the file before it.
⁴ Given '-i "a/b*" -o "x/" -m "a/"' output is "x/b/...".
Given '-i "a/b*" -o "x/" -m "a/b/"' output is "x/...".
Given '-i "a/b*" -o "x/" -m "not-a/"' output is "x/abs-path-to-input/...".
Local Development Setup
Prequisites for Running
Quick Start
-
(initially) Install dependencies:
npm ci
-
(optional) Make changes to /src/lib
files.
-
Build the styles*:
npm run build:css
-
Build and preview the styles*:
npm start
-
(to debug) Review output in respective /dist
or /demo
files.*
* Stylesheets are built from source files in src/lib
directory to compiled files in dist
directory.
Preview After Development
-
Build stylesheets and build static demo:
npm run build
-
Run the static demo:
npx serve demo
Web page will live-reload on demo build, but not on change of source files.
-
Open the web interface.
The build command will output the URL (and may even open it for you).
Preview During Development
Run each of these commands in its own terminal.
-
Build stylesheets and re-build on change:
npm run watch
-
Run the auto-refresh demo:
npm run start
Web page will live-reload twice on change of source files. The second reload will show changes.
Build Options
Regular CSS Build
npm run build:css
Custom Build ID
npm run build:css -- --build-id="..."
Testing
All testing is done manually.
Deployment
Production Deployment
The Core Styles are not independently deployed.
Currently, the demo is served by Core CMS (since v3.9.0).
Later, the demo may be deployed indpendently and core-styles.….css
served from a CDN.
Contributing
Development Workflow
We use a modifed version of GitFlow as our development workflow. Our development site (accessible behind the TACC Network) is always up-to-date with main
, while the production site is built to a hashed commit tag.
- Feature branches contain major updates, bug fixes, and hot fixes with respective branch prefixes:
task/
for features and updatesbug/
for bugfixesfix/
for hotfixes
Best Practices
Sign your commits (see this link for help).
Publishing Workflow
Only authorized team members may publish.
- (one time) Login to npm via:
npm login
- Create new branch for version bump.
- Update
CHANGELOG.md
. - Update version via:
npm version N.N.N
- Update dist via:
npm run build:css --build-id=vN.N.N
- Commit, push, PR, review, merge.
- Create release and tag on GitHub.
- Replace Github's unannotated tag with an annotated one:
git tag -d vN.N.N
git tag -a vN.N.N -m "..."
git push --tags --force-with-lease
- Publish to NPM via
npm publish --access public
.
Project build will automatically occur before publish. - Commit NPM build output as:
chore: save npm publish build
Resources