A Website built on with
Built with:
- Node.js 12+
- git
- re-run the install:
npm install
- If you encounter an error with node sass, do a rebuild:
npm rebuild node-sass
Command | Purpose |
---|---|
npm install |
Installs all packages |
npm run clean |
Deletes the build folder |
npm run build |
Builds all assets for a development environment |
npm run build:staging |
Builds for staging (only assets, unminified) |
npm run build:production |
Builds for production (only assets, minified) |
npm start |
build for development, watches source folders, live reloading |
npm run lint:styles |
runs linter on all scss files in src, outputs in console and reports/scss.lint.txt |
npm run lint:js |
runs linter on JS files in src, output in console and reports/js.lint.txt |
npm run lint:js:fix |
runs lint:js and fixes all fixable things |
npm run lint |
runs lint:styles and lint:js |
npm run test:ui |
runs jest --maxworkers=2 |
npm run test |
runs test:ui and has linting as a posttest |
Docker isn't necessary, but may be useful if you don't want to change your version of node or NPM. It allows you to run the front-end static site in a container. You can then use VS Code's WSL extensions to connect to it.
Be mindful that the container will not run Puppeteer.
You can always give your own tag. Take note of the .
at the end.
docker build --tag WEBSITE-front-end .
You can always give your own name. Take note that this binds port 3000 from the container to port 3000 on your machine. You could bind it to your own port.
docker create --name exlrt-front-end-local -p YOURPORT:3000 WEBSITE-front-end
docker run WEBSITE-front-end-local
docker run --rm --name WEBSITE-front-end-local -v "%cd%":/app -w /app WEBSITE-front-end npm COMMAND
docker
docker exec -it WEBSITE-local-site bash
If using VSCode, install the Jira Extension. The Jira extension lets you view issues, start branches from them, and create pull requests.
You can view Jira issues with this extension with the following JQL:
project = "WEBSITE-JIRA-PROJECT" AND assignee = "<YOUR NAME>" AND status != "resolved" AND status !="closed" AND Sprint = <SPRINT NUMBER> ORDER BY priority DESC
- New works starts as a branch off of
develop
.- Set ticket to "in progress"
- Follow the "gitflow" style with branch names Use a prefix, include the ticket number, optionally choose a description of the work.
feature\WEBSITE-JIRA-123
bugfix\WEBSITE-JIRA-456-correct-everything-in-ie
hotfix\WEBSITE-JIRA-IE-didnt-work
- After local testing is finished submit a pull request to merge into
develop
- Double check linters to make sure there's no errors
- Did you look at in Firefox, IE11, and mobile?
- Set ticket to "on hold"
- After the pull request is approved, merge develop into
staging
branch- Set ticket to "To deploy"
- Every Tuesday and Thursday, the
staging
branch is deployed to uat.exlrt.com.- Set ticket to "in review" and assign to tester or whomever opened it.
- After ticket is reviewed, it should be moved to "done"
- Write working code
- Write good code
- Write fast code
- Don't commit code that would make a teammate curse your name
- Note: Future You is also a team mate
- Follow ITCSS pattern
- Be BEM-ish:
- camelCase for multiple words
- use hyphens to indicate "elements"
- Use modifiers on the block for variations
- Give all variables semantic names, even colors, following small rules for naming things.
- Follow the stylelintrc.json, with extras:
- indent 2 spaces
- strings should be double quotes
- classNames should be camelCased
- Don't nest more that 2 levels deep
- Seriously, seriously reconsider using
:not
@extends
is against the law.
!important
is permitted for utilities only- CSS must be accessible
- don't use
display: none
if it contains text, screen readers can't find it - Where you add
:hover
,:focus
must follow
- don't use
- Generally follow Harry Roberts' CSS Guidelines
- Don't override or ignore lint errors, lint warnings, or Industry Best Practices without leaving a comment explaining why.
- prefer
===
- Use semicolons
- Put JS in a
class
and instantiate it inindex.js
- Use JSDoc to document all functions, classes, and methods
- Generally follow AirBnB's JS style guide; it will not lead you astray.
- Don't override or ignore lint errors, lint warnings, or Industry Best Practices without leaving comments explaining why.
- HTML must be valid
- HTML must be semantic
- HTML must be accessible
- Do not abstract HTML into templating if it leads to a loss of understanding for back-end developers
- All partials should be commented explaining what parts are content manageable, what kinds of output are expected, and what any logic rules are expected.
- Don't ignore Industry Best Practices without leaving a comment explaining why
- Use real images whenever possible. Placekitten, placeimg, placebear, and baconmockup are fun, but may not reflect what goes into the CMS
- Use real real content whenever possible. Lorem ipsum does not reveal how a CMS user will author content.
/
├── src
│ ├── css
│ │ └── index.scss
│ ├── data
│ │ ├── replacements.json
│ │ └── site.json
│ ├── fonts
│ ├── img
│ ├── js
│ │ └── index.js
│ ├── views
│ │ ├── layout
│ │ │ └── default.hbs
│ │ ├── partials
| | | └── *.hbs
│ │ ├── helpers
| | | └── *.js
│ │ ├── pages
| | | └── *.hbs
├── gulpfile.js
│ ├── functions
│ | └── *.function.js
│ ├── tasks
│ | └── *.task.js
│ ├── config.js
│ ├── index.js
├── .babelrc
├── .editorconfig
├── .eslintrc
├── .stylelintrc.json
└── env.config.js
Note: Development and staging builds have -development and -staging postfixed to the file names.
Development:
/
├── build
│ ├── assets
│ │ └── css
│ │ └── fonts
│ │ └── img
│ │ └── js
| ├── index.html
| └── *.html
Staging, Production:
/
├── build
│ ├── assets
│ │ └── css
│ │ └── js