Front-End starter kit by Studio 24.
These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for how to deploy the project to staging and live environments.
Also see more detailed project documentation.
A step-by-step set of instructions that tell you how to get your local dev environment running.
Clone repo:
git clone git@github.com:studio24/amplify.git
Install PHP dependencies:
composer install
Install project dependencies:
# Switch your version of Node to the correct version for this project (see `.nvmrc`)
nvm use
npm install
Build front-end assets:
npm run build
There are also specific commands if you only want to build certain front-end assets:
nvm use
# Copy font assets to the `dist` directory
npm run fonts
# Copy image assets to the `dist` directory (note they are **not optimised** as part of this step)
npm run images
# Optimise and then copy SVG assets to the `dist` directory
npm run svgs
# Compile the Sass partials into CSS files in the `dist` directory
npm run styles
# Compile, transpile and minify the JS files, place them in the `dist` directory
npm run js
Watch for changes:
npm run watch
If needed, update the package.json
file in the project root to specify which browsers are supported (referenced by the CSS and JS build tools) and manage the packages and NPM scripts required to build the site assets.
SVG Optimizer is used to optimise SVG files. There is a svgo.config.js
file in the project root to determine optimisation settings.
Webpack is used to compile, transpile and minify JavaScript files. There is a webpack.config.js
file in the project root which controls this process.
If there are libraries that you would like to use as is in your project, set up Webpack to copy them across from the src folder to the dist folder.
In the webpack.config.js
file, add a 'from-to' pattern to the CopyPlugin configuration parameters, using the syntax:
{ from: "./../../node_modules/[node_package_name]/[path to the js file]]", to: "./libraries" }
In the webpack.config.js
file, uncomment the following line from the CopyPlugin configuration parameters:
// { from: "./libraries/", to: "./libraries" },
You can now add the script to the assets-src/js/libraries
folder and run the full build script or the 'webpack-expanded' script.
Create a new branch for your work, when you are ready for your changes to be integrated into the main branch, create a new release commit (if you haven't done so already), push to the repo, and issue a PR into main. All merge requests need to be authorised by a Code Owner
Once the PR is accepted, you can merge your branch into main. A new release will then be automatically generated.
A release is a new version of Amplify, tagged with a version number (e.g. 1.2.0). The current version number can be found in the file version.txt
.
Each release can be revisited separately in Github, e.g. when you want to look up documentation or code related to a legacy version of Amplify.
Each release comes with an associated .zip file that contains the assets-src
folder and the build scripts for that version.
Note you can create a new release even if your work is still in progress and not just yet ready to merge into main. Further commits can be made to the branch. PRs to the main branch will need review by another dev.
First, decide on the level of the release (see https://semver.org/ for full details):
- patch: quick fix, no new feature (e.g. going from 1.0.0 to 1.0.1)
- minor: new feature, no breaking change (e.g. going from 1.0.0 to 1.1.0)
- major: major release, new features or refactoring with breaking changes (e.g. going from 1.0.0. to 2.0.0)
To create a new release use conventional commits in your commit message. Their syntax is as follows:
- To create a new patch version -
fix:
Example:fix: fixed typo in JS file comment
- To create a new minor version -
feat:
Example:feat: added carousel component
- To create a major version - there are two possible ways:
fix!:
orfeat!:
Example:feat!: updraging CSS properties, not compatible with IE11 anymore
- Alternatively, add a footer of
BREAKING CHANGE:
with details of what breaking changes there are. See example below
$ git commit -m "feat: upgrading css syntax
FOOTER latest CSS properties not compatible with IE11 anymore
"
This repo uses Release Please to automatically create releases, based on semantic versioning. If the action fails to run you can view the action under https://github.com/studio24/amplify/actions and re-run it (full instructions on re-running actions: https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs).
The site uses Deployer for deployment (installed via Composer). Please note if no branch is specified your current branch is used.
You should always deploy the main
branch to production.
./vendor/bin/dep deploy production --branch=main
The deploy process outputs a summary of what branch is currently deployed to staging, please check this to ensure you're not overwriting someone's work.
./vendor/bin/dep deploy staging --branch=branch-name-to-deploy
- Nicola Saunders - Front-End Lead Developer - Studio 24
- Marie Manandise - Senior Web Developer - Studio 24
The MIT License (MIT). Please see License File for more information.
Inspired by Springer Nature Front End Playbook, Every Layout and CUBE CSS