We offer a convenient versioning management approach for releasing software on GitHub.
5 posts tagged with "Frontend"
View All TagsCypress E2E Tests
This action assumes the yarn package manager is used.
Cypress E2E action offers an easy way to automate, customize, and execute parallel end-to-end tests. The action provides
- dependency installation via yarn,
- scanning of test specs,
- running each spec in parallel, and
- upload test screenshots and video on test failure.
The example below is a very simple setup:
-
Install Cypress with
yarn add cypress --dev
-
Initialize Cypress with
yarn run cypress open
-
Put all .spec.cy.ts test files under "cypress/e2e" directory
-
Install wait-on:
yarn add -D wait-on
-
Add the following script command to
package.json
:{
...
"scripts": {
"e2e": "cypress run --browser chrome",
"wait-on-dev": "wait-on http-get://localhost:3000/",
"wait-on-prod": "wait-on http-get://localhost:3000/"
},
...
}infoNote that we assume the UI is running at port 3000. Please adjust it accordingly if it's running at a different port.
-
Use Cypress E2E Tests workflow:
---
name: CI/CD
"on":
pull_request:
push:
branches:
- master
e2e-tests:
name: Unit Tests
needs: unit-tests
uses: QubitPi/hashistack/.github/workflows/cypress-e2e.yml@masterIn the example above, the node 18 is used in the CI/CDed project by default. A list of custom node versions can be used to replace the default. For example, to run E2E tests in node 16, 18, and 20, simply use node-versions parameter:
---
e2e-tests:
name: Unit Tests
needs: unit-tests
uses: QubitPi/hashistack/.github/workflows/cypress-e2e.yml@master
with:
node-versions: '["16", "18", "20"]'
Inside the cypress-e2e
workflow, each [Cypress spec] is tested in 2 modes:
- yarn-start: the web app is started using
yarn start
- server: a production build is generated first using
yarn build
and then the web app is started withyarn serve
The reason we run the same E2E in 2 separate modes is that we assume E2E testing consists of 2 logical parts:
- The logical tests defined by Cypress spec files
- The same tests in the context of integration of web app logic and the production runtime github-actions-core
The app may work perfectly fine in E2E, but it's a different question when the same app is packaged up using, for example, webpack. The later could also be interpreted as integration tests against webpack configuration which makes the tests more comprehensive
NPM Release action
The NPM release action bundles up a React/Vue package and publishes it to npm registry.
To use the release action, create a GitHub Secret for npm token, which will be used to authenticate against NPM in the action. Then use the following template in CI/CD:
name: CI/CD
"on":
pull_request:
push:
branches:
- master
env:
NODE_VERSION: 18
jobs:
publish:
name: Publish Package to NPM
if: github.ref == 'refs/heads/master'
runs-on: ubuntu-latest
steps:
- uses: QubitPi/hashistack/.github/actions/npm-release.yml@master
with:
node-version: ${{ env.NODE_VERSION }}
npm-token: ${{ env.NPM_TOKEN }}
user: Qubitpi
email: jack20220723@gmail.com
UI Unit Test
The UI unit test action runs unit tests and assumes the yarn package manager and requires a test
script to be
defined in projects package.json
file. For example, the following uses Jest as the unit test runner:
{
"scripts": {
"test": "jest"
}
}
To use this action, import it in the following way:
name: CI/CD
"on":
pull_request:
push:
branches:
- master
unit-tests:
name: Unit Tests
uses: QubitPi/hashistack/.github/workflows/ui-unit-test.yml@master
with:
node-version: 18
In the example above, the node 18 is used in the CI/CDed project.
The example above uses Node version 18, which is specified in NODE_VERSION
environment variable
UI Code Style
In Frontend dev realm, there are lots of code style checker. Assembling all of them together takes efforts and pains. This action runs the following two code style checker specifically for frontend dev:
This action assume ESLint, typescript-eslint, and Prettier have been installed, which can be done with:
yarn add --dev @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint typescript
yarn add --dev --exact prettier
Here is an example usage of the action:
name: CI/CD
"on":
pull_request:
push:
branches:
- master
code-style:
name: React & TS Code Style Check
uses: QubitPi/hashistack/.github/workflows/ui-code-style.yml@master
with:
node-version: 18
In the example above, the node 18 is used in the CI/CDed project.
The configurations of Prettier and ESLint can be done regularly by following their respective documentations. For example, the .prettierrc.json and .prettierignore can be placed at the project root with the following contents:
{
"tabWidth": 2,
"useTabs": false,
"printWidth": 120
}
*.md
*.mdx
build
coverage
node_modules
We can fix it by formatting all files at the root of project with:
yarn prettier . --write
Initial ESLint configuration template can be generated with
yarn run eslint --init # https://dev.to/maithanhdanh/configuration-for-eslint-b47
Linters usually contain not only code quality rules, but also stylistic rules. Most stylistic rules are unnecessary when using Prettier, but worse - they might conflict with Prettier! Use Prettier for code formatting concerns, and linters for code-quality concerns, as outlined in Prettier vs. Linters.
Luckily it's easy to turn off rules that conflict or are unnecessary with Prettier, by using these pre-made configs:
yarn add --dev eslint-config-prettier