Skip to main content

5 posts tagged with "Frontend"

View All Tags

· 2 min read
Jiaqi Liu
info

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:

  1. Install Cypress with yarn add cypress --dev

  2. Initialize Cypress with yarn run cypress open

  3. Support TypeScript

  4. Put all .spec.cy.ts test files under "cypress/e2e" directory

  5. Install wait-on: yarn add -D wait-on

  6. 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/"
      },

      ...
    }
    info

    Note that we assume the UI is running at port 3000. Please adjust it accordingly if it's running at a different port.

  7. Use Cypress E2E Tests workflow:

    ---
    name: CI/CD

    "on":
      pull_request:
      push:
        branches:
          - master

      e2e-tests:
        name: Unit Tests
        needs: unit-tests
        uses: QubitPi/hashicorp-aws/.github/workflows/cypress-e2e.yml@master

    In 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/hashicorp-aws/.github/workflows/cypress-e2e.yml@master
        with:
          node-versions: '["16", "18", "20"]'
tip

Inside the cypress-e2e workflow, each [Cypress spec] is tested in 2 modes:

  1. yarn-start: the web app is started using yarn start
  2. server: a production build is generated first using yarn build and then the web app is started with yarn serve

The reason we run the same E2E in 2 separate modes is that we assume E2E testing consists of 2 logical parts:

  1. The logical tests defined by Cypress spec files
  2. 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

· One min read
Jiaqi Liu
tip

This action works for both npm and yarn package managers

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/hashicorp-aws/.github/actions/npm-release.yml@master
        with:
          node-version: ${{ env.NODE_VERSION }}
          npm-token: ${{ env.NPM_TOKEN }}
          user: Qubitpi
          email: jack20220723@gmail.com

· One min read
Jiaqi Liu

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/hashicorp-aws/.github/workflows/ui-unit-test.yml@master
    with:
      node-version: 18
tip

In the example above, the node 18 is used in the CI/CDed project.

tip

The example above uses Node version 18, which is specified in NODE_VERSION environment variable

· 2 min read
Jiaqi Liu

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:

  1. Prettier
  2. ESLint

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/hashicorp-aws/.github/workflows/ui-code-style.yml@master
    with:
      node-version: 18
tip

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:

.prettierrc.json
{
  "tabWidth": 2,
  "useTabs": false,
  "printWidth": 120
}
.prettierignore
*.md
*.mdx
build
coverage
node_modules
tip

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
Prettier & ESLint Conflict

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