The new Hedwig Design System is now stable and can be found here. This repository will be minimally maintained.
npm install
npm run dev
We will not support changes and updates on older major releases of Hedwig. Users of the Hedwig repo are responsible for
- Staying up to date on changes made - in code and guidelines.
- Following the guidelines, which also include best practices and correct brand implementation.
This repo is public, so please consider this when contributing
- Create a new issue.
- If you want to fix this issue yourself, do so and then follow the development giuidelines below.
First of all: let the community know on the internal #hedwig slack channel what you need and how you plan to solve it. There might be other teams that also would benefit from your solution. Either way there will probably be one of two outcomes:
If you are adding new functionality to Hediwg please follow the below development giuidelines below.
If the thing you're changing or adding is specific to your project, and not all sites using Hedwig, use a separate css file to add or override functionality using your own classes and components.
- It is recommended to always develop the components within the documentation. The docs will live reload.
- All components should do one thing, and do that thing well.
- All CSS should be written to adhere to the BEM methology.
- All JS should be classless and use
data-attributesto attach functionality. - New functionality should be reviewed by at least one other person before going into Hedwig.
To add a new feature:
- Create a new feature branch (
git checkout -b branchname) - Develop the new feature (Template css and js files can be found in the
/templatesfolder) - Document and test the new feature
- Create a pull request and ask for a review
To modify an existing feature follow the same process, but also remember the versioning system. If there is a breaking change, or if this might impact existing sites using hedwig, update the version number. See below for details.
clone this repo
npm install # to install dependencies
npm run dev # start local development server
Tip: In order to test changes on a locally running application which uses hedwig, replace the dependencies with the following dev server URLs (after running hedwig locally):
http://localhost:3001/posten.css
http://localhost:3001/main.js
The staging environment is setup in Heroku as a separate app. All the assets are copied to docs folder and referred from there in this branch.
Pushing a new change will automatically deploy the app in Heroku.
setup_staging task need to be run whenever the staging branch is reset. It copies the scripts/Procfile to the root folder. Commit and push the file in staging branch only.
master branch shouldn't have a Procfile.
Hedwig uses semantic versioning to make sure once a site starts using it, the CSS file won't suddenly change and break the site. The version number is located in package.json, and will be appended to the .css and .js files. Example - bring-1.0.3.css.
When a breaking change is added, a new major version is required.
Production CSS, JavaScript and assets are served through a CDN using jsDelivr.
We use FontAwesome for functional icons. Not all FontAweseome icons are available in Hedwig You will find available icons here. If you need to use an icon from FontAwesome that is not allready added in Hedwig you need to add it and open a pull request.
- You need to add an environment variable with your authToken from Font Awesome. For Posten and Bring developers, contact Hedwig contributors. Otherwise, you can get a licence.
- Use functional icons like described in the docs
To add the authToken to your environment, in ~/.bashrc add the following line:
export NPM_TOKEN=[authToken]
The token needs to be replaced by a real token.
Hedwig use SVG sprite for special icons and logos. These icons must only be used in conjunction with its service or service name.
- Place icons in the
assets/icons/folder - Run
npm run svgto generate SVG sprite.npm run buildornpm run devwill both also produce the SVG sprite
We use inline SVG's for icons.
Linting our project is import to keep a holistic code base. It is recommended to use a linting plugin for your editor while developing.
JavaScript uses ESLint with the Airbnb config.
CSS uses Stylelint with the standard config.
The /scripts folder contains a set of custom scripts that helps compile the docs.
List of npm scripts:
dev: Starts the watcher and starts the node server (in development mode)
Q: I have a question! Who do i ask? A: Use the Hedwig slack channel!
The Hedwig Team is resposible for maintaining the Hedwig repo. Contact us with any questions or feedback either in the #hedwig Slack channel or [email protected]
development helpers:
- PostCSS, cssnano, postcss-cli, postcss-cssnext, postcss-extend - for transpiling CSS
- sanitize.css to make CSS sane (a lightweight version of Normalize)
- stylelint, stylelint-config-standard - for litning CSS
- RollUp, rollup-plugin-babel, rollup-plugin-commonjs, rollup-plugin-multi-entry, rollup-plugin-node-resolve, rollup-watch - for transpiling JavaScript
- Babel, babel-preset-es2015, babel-cli, babel-jest - to use ES6 syntax
- Jest - for JavaScript unit testing
- Lodash - for JavaScript utility functions (rest is vanilla JavaScript)
- eslint, eslint-plugin-import, eslint-config-airbnb, eslint-plugin-jsx-a11y - for linting JavaScript
- express, live-reload, node-watch - for developemnt
- s3, aws-sdk, dotenv - for deployment
- concurrently - to run multiple scripts
- Catalog - for documentation
- svgo, svg2sprite - for SVG's
included in bundle:
- Zenscroll - Tiny smooth-scroll helper
- Source code is licensed under BSD 2-Clause
- All icons and images are licensed under Creative Commons Attribution-NoDerivatives 4.0