dvsa / front-end

DVSA Front-end application built on Node/Express. It uses SCSS, Nunjucks, ES6, WebPack, Babel, and Docker.

Localdev setup

1. Run npm install in the root directory of front-end

2. Make changes to your code

3. Build assets using docker-compose run app npm run build-production

4. Refresh the page NOTE: If you want to update the assets for MTS, the easiest way is to take the Styles.css file

   front-end/dist/assets/stylesheets/styles.css and copy it's content to

mot/mot-web-frontend/public/assets/stylesheets/styles.css and then refresh the page.

For the old stylesheets:

1. Modify the relevant sass file under mot/mot-static
2. Run: sass app.scss app.scss This will generate a new app.css which will contain your changes (even if you modified a different sass file such as buttons.scss in mot-static)
3. Copy the newly generated app.css file intomot/mot-web-frontend/public/css/
4. Refresh the page.

Deploy to Jenkins

1. Update front-end/composer.json with an incremented front-end version number.
2. Run composer update to update the composer.lock file
3. Update package.json and package.lock with an incremented version number.
4. Commit your changes
5. Run git tag -a 1.5.x -m "Updated assets" to tag your latest commit
6. Run git push origin 1.5.x to push the new asset version
7. Under web-frontend/CVR/MOTH/MOTR update the composer dependancy to point to the new version.
8. Run the Jenkins build.

Further details and guidance for using this kit for prototypes and releases for MTS can be found internally in Confluence by searching for front-end.

Demo

You can view the MOT component library and prototypes here:

Heroku Demo

Login credentials

If you'd like to access the Prototypes pages, log in as below. The prototype system is password protected to prevent users accidentally accessing what may look like a real Government Service.

User: admin
Password: dvsa

OLD Local Setup

Prerequisite

1. Clone this repo and cd into the directory using terminal

2. Install dependencies using NPM

docker-compose run app npm install

Development

To run development mode run the following command inside the directory.

docker-compose up

You can access the local server with the following url

http://localhost:3002

It will automatically run the following processess concurrently

• gulp start-dev task
• webpack with development configurations
• express application with nodemon

Build Production

Build production command will generate production ready assets and node js server code.

The productions assets are located in the dist/assets folder and the server code is located in the dist/server folder.

docker-compose run app npm run build-production

Run this command and commit changes before pushing to heroku.

Docker setup for development

You will need the latest version of docker installed

Running development mode

For faster development you can use docker by running the following command:

docker-compose up

After which the server is located at the local address below:

http://localhost:3002

Building production assets

Run the following command

docker-compose run --rm app npm run build-production

front-end's Issues

Tracking confidence in custom and extended MTS components

How might we best demonstrate our level of confidence in new or adapted components within MTS and the DVSA design system?

We know that some components may be best replaced by more recent GDS components with a greater weight of research and breadth of use. Also, there are a number of components where we have a degree of confidence that they are serving a genuine user need that could not be wholly fulfilled by an existing component within the GDS design system. This confidence will vary depending on the research we have carried out, and their ubiquity of use elsewhere (other GDS services, de facto standards elsewhere on the internet).

In all cases, it would be useful to be able to illustrate and track that confidence in order that we can more efficiently target future research and/or feed back to the GDS community backlog.

There are a few thoughts about how to achieve this; largely within the design system itself. I would suggest that each custom MTS component or pattern should have an issue against it where we can share findings and discussion; also enabling it to be open to the wider community.

What are your thoughts? @rafaldrewnowski @MartinDM @campbellm104

Examples:

Recent blog post by Eliot Hill (https://hodigital.blog.gov.uk/2018/09/07/documenting-design/)

HMCTS labels e.g. [Experimental]: (http://hmcts-design-system.herokuapp.com/components/timeline)

HMCTS backlog: (https://github.com/hmcts/design-system-backlog/issues)

Opening up the DVSA component library

Since other Gov't service digital teams (such as Home Office) make their component systems available publicly, should we also consider doing the same for our library too, if not the prototypes themselves?

This would
...mean we can reference components in the system and provide working links to them, and allow them to be used by other teams.

Allow MOT components to be adapted for other teams with similar use cases as the 'MOT-only' notice might be a bit restrictive if there's a use case for others.

Allow us to expand what we have alongside the component library to include other resources, publish research findings and notes?

Thoughts?

Ref: Home Office Design system
https://home-office-digital-patterns.herokuapp.com/components

access to the demo

Hi! is it possible to access the link to the demo? it's behind a login.