This is a monorepo containing the elements required for building experiences following the EnergySage Design System of es-ds for short.
This repository es-ds
is public and the contents are licensed under the
MIT
For that reason discussion and documentation specific to EnergySage should probably be kept within private org channels.
For EnergySage specific resources & channels see the Quick Links section of the Design System confluence page
The EnergySage Design System is composed of 2 core npm packages:
graph TB
subgraph es-ds
subgraph "@energysage"
A["@energysage/es-bs-base"]
C["@energysage/es-vue-base"]
end
D[es-design-system]
C-->D
end
Y(nuxt2)
Z(vue-bootstrap) --> C
Y-->D
es-bs-base started as a fork bootstrap 4.
This package overrides the _variables.scss
file in bootstrap to the ones use
defaults required by the energysage design system.
There's additional variables and colors that diverge and extend from the core bootstrap framework.
Additionally the SASS has been refactored to use the modular system and dart-sass compiler.
es-vue-base
has a peer-dependency of
bootstrap-vue which is used for vue components.
Associated styling is vendorized in es-bs-base
and re-written using the SASS
modular system.
es-vue-base contains vue components for use in nuxt projects. It has a dependency of bootstrap-vue as components extends or are composed of bootstrap components.
es-bs-base
is a sibling dependencies and should provide the baseline CSS
styling to vue rendered components.
This is our design-system documentation branch, and reference integration for
the es-ds
packages.
clone git@github.com:EnergySage/es-ds.git
When publishing changes you will commit to the origin branch of the es-ds repo. So your git set-up should look like this:
$ git remote -v
origin git@github.com:EnergySage/es-ds.git (fetch)
origin git@github.com:EnergySage/es-ds.git (push)
make install
- installs all packages from npmmake update-peer-deps
- installs necessary peer deps fores-vue-base
used ines-design-system
make build-scss-pkg
- buildes-bs-base/dist
locally; we do this first sincees-vue-base
imports it@import '~@energysage/es-bs-base/scss/includes'
make symlink
- symlink or bootstrapes-bs-base/dist
make build-vue-pkg
- buildes-vue-base/dist
locallymake symlink
- symlink or bootstrapes-bs-base/dist
andes-vue-base/dist
for use ines-design-system
To develop with hot reloading for all packages you'll want to run make dev
in
the es-ds
directory. This will build and package es-bs-base
and
es-vue-base
and symlink them to es-design-system
for use in the nuxt app. It
will then start a dev instance for es-design-system
that will be available at
http://localhost:8500
.
Hot reloading will take longer than a typical nuxt app, as it will need to rebuild the packages and re-link them. This is expected.
In a terminal run:
find es-vue-base/src/ | entr -s 'npm --prefix es-vue-base run build'
(You may need to run brew install entr
first)
In another terminal run:
(cd es-design-system && FAST_LOCAL=true npm run dev)
This will result in much faster reloads that skip rebuilding all of es-bs-base
as well as skipping server-side rendering. But note this will also throw an
error in webpack-dev server until es-vue-base
finishes compiling, then it
should recover.
You must also ensure things work server-side before committing your changes.
Once we upgrade to Lerna 6, this should all be much faster & smoother via native Workspace watching
When adding vue components to es-vue-base, it is expected that you also write unit-tests.
At a minimum it's recommended you create a snapshot test to catch any potential regressions in rendered output. Depending on complexity further tests may be required.
Tests can be run via make test
, but this will run tests for all packages in
the repo. For faster feedback, you can cd es-vue-base
and run npm run test
to only run tests for the es-vue-base package.
Once tests are passing, you'll need to rebuild the es-vue-base package. This
can be done via npm run build
.
Next you'll want to move back to the root of the monorepo, and run make symlink
. This will ensure the new package is sym-linked to the other projects
in the monorepo.
Once your changes have been made, you'll want to ensure they're documented
somewhere in es-design-system
. If the change is a new component, it's expected
you'll create a new page to display the component.
Note This step also functions as a form of integration testing as it will validate the component will import and render on a nuxt page.
In your PR, make sure to include a section in the changelog documenting your change. Following keep a changelog conventions this will look similar to the following:
## [Unreleased]
### Added
- Thing one
### Changed
- Thing two
This will make it easier to ensure all changes merged into main
are captured
in the changelog when publishing a new release.
For simplicity of deployment, versioning of packages are fixed and updated together.
Assuming changes are approved, the process of publishing a new version is...
- Ensure your local environment is
setup and you are on
the
main
branch npm login
- Logs you into the npm.js registry. You'll need access to oures-ds
package there in order for things to work.make install && make symlink
- Install the new published versions locally and symlink themmake build
- Build all packages to*/dist
folders locallymake lint && make test
- Run tests and linting to ensure they passmake publish
- Publish updated packages to npmjs.com- Update CHANGELOG.md with our newly published changes
make install && make symlink
- Install the new published versions locally and symlink themgit commit -m "docs: :memo: add version X.X.X to the changelog" && git push
- Commit and push the changelog andpackage-lock.json
updates- For updating the design-system website see Deploy Design System
Running make publish
will trigger the following prompt:
lerna info Looking for changed packages since v0.1.9
? Select a new version (currently 0.1.9)
❯ Patch (0.1.10)
Minor (0.2.0)
Major (1.0.0)
Prepatch (0.1.10-alpha.0)
Preminor (0.2.0-alpha.0)
Premajor (1.0.0-alpha.0)
Custom Prerelease
Custom Version
You'll note the lerna script will walk you through versioning, then push your changes, and tag the release in git.
This project follows semantic versioning. Please make sure your change in version reflects the semantics defined via semver. At a high level the guidelines are:
- MAJOR version changes introduce incompatible API changes. API changes could
mean:
- removal of core-components used in other verticals
- changing "props" of core-components causing breaking changes in other verticals
- MINOR version changes add functionality in a backwards compatible manner.
This could mean:
- changing the hex value represented by the variable
$white
ines-bs-base
- adding an additional "prop" to a core-component, but otherwise not chancing the default behavior
- changing the hex value represented by the variable
- PATCH version changes are backwards compatible bug-fixes and should have no impact on functionality aside from fixing a bug