Skip to content

Latest commit

 

History

History
210 lines (140 loc) · 8.78 KB

development.md

File metadata and controls

210 lines (140 loc) · 8.78 KB

Development

Prerequisites

Development and building the service locally requires Node.JS (>= 18) with PNPM as a package manager -- and Git, obviously.

To start with development, use e.g. NVM to install an appropriate version of NodeJS, then install PNPM. Once that is done you can check out the repo with git, and install the dependencies with PNPM.

Husky is used for git commit hooks in combination with lint-staged. Turborepo is used to handle builds and testing.

Rebuilding on file changes

During development it is helpful to rebuild the main package and dependencies when files change. To do this, run the dev script in a new terminal:

pnpm dev

Testing - E2Es

E2E tests can be run locally via:

pnpm test:e2e-local
pnpm test:e2e-mac-universal-local

Below are the task graphs for the E2Es:

E2E Task Graph

Mac Universal E2E Task Graph

Testing - Units

Unit tests (using Vitest) can be run via:

pnpm test:unit

...in the root to run all of the tests for each package, OR

pnpm test:dev

...in each package directory to run tests in watch mode.

Updating Dependencies

Dependencies can be updated interactively via:

pnpm update:all

Updating E2E Task Graphs

Task graphs can be updated by running:

pnpm graph

Formatting

The repo uses Prettier for formatting. It is encouraged to format code on save using, e.g. the Prettier plugin for VSCode, however it is not a requirement; Husky is configured to run Prettier on git pre-commit hook to ensure consistent formatting across the repo.

Prettier can be invoked manually via:

pnpm format

And a formatting check (without updating any files) can be performed via:

pnpm format:check

Linting

ESLint is used for linting, it can be performed via:

pnpm lint

and to apply auto-fix for issues raised:

pnpm lint:fix

Contributing

Check the issues or raise a new one for discussion:

Help Wanted Issues Good First Issues

Release

Project maintainers can publish a release or pre-release of the npm package by manually running the Manual NPM Publish GitHub workflow. They will choose the release type to trigger a major , minor, or patch release following Semantic Versioning, or a pre-release.

Publish a Release

To publish a release, run the release workflow with the defaults for Branch main and NPM Tag latest, and set the appropriate Release Type (major, minor, or patch). This will:

  • Create a Git tag
  • Create a GitHub Release
  • Publish to npm

Publish a Pre-Release

To publish a pre-release, also referred to as a test release, run the pre-release workflow with the NPM Tag next. This will:

  • Create a Git tag with the -next.0 suffix
  • Create a GitHub Pre-Release
  • Publish to npm

Use the Release Type to control which version to increment for the pre-release. The following table provides examples for publishing a pre-release from the current version 6.3.1:

Release Type Pre-Release Version
major 7.0.0-next.0
minor 6.4.0-next.0
patch 6.3.2-next.0
existing 6.3.1-next.0

To create consecutive pre-releases you can select existing which will increment the pre-release version in the suffix. For example, if the current version is 6.3.1-next.3, the following will be published:

Release Type Pre-Release Version
major 7.0.0-next.0
minor 6.4.0-next.0
patch 6.3.2-next.0
existing 6.3.1-next.4

Maintenance policy

Starting from v8 the team intends to backport all features that would be still backwards compatible with older (maintained) versions. With a new major version update (e.g. v8) we continue to maintain the previous version (e.g. v7) and deprecate the previously maintained version (e.g. v6 and lower).

Backporting Bug Fixes

In accordance with the maintenance policy, do the following to ensure that backwards-compatible fixes are reflected in the maintenance version.

As a Triager

Anyone making a triage or reviewing a PR should label it with backport-requested if the changes can be applied to the maintained (previous) version. Generally every PR that would not be a breaking change for the previous version should be considered for backporting. If a change relies on features or code pieces that are only available in the current version, then a backport can still be considered if you feel comfortable making the necessary adjustments. That said, don't feel forced to backport code if the time investment and complexity is too high. Backporting functionality is a reasonable contribution that can be made by any contributor.

As a Merger

Once a PR with a backport-requested label is merged, you are responsible for backporting the patch to the older version. To do so, pull the latest code from GitHub:

git pull
$ git fetch --all
$ git checkout v7

Before you can start, you will need to create the file .env in the project root with the access token set as GITHUB_TOKEN in order to allow the executing script to fetch data about pull requests and set proper labels. Go to your personal access token settings page and generate such a token with only the public_repo field enabled. Then copy the token to the .env file and run the backport script. It fetches all commits connected with PRs that are labeled with backport-requested and cherry-picks them into the maintenance branch. Via an interactive console you can get the chance to review the PR again and whether you want to backport it or not. To start the process, just execute:

pnpm run backport

If during the process a cherry-pick fails, you can always abort and manually troubleshoot. If you are not able to resolve the problem, create an issue in the repo and include the author of that PR. A successful backport of two PRs will look like this:

$ pnpm run backport

> webdriverio-monorepo@ backport /path/to/webdriverio/webdriverio
> node ./scripts/backport.js

Welcome to the backport script for v7! 🚀

================================================================================
PR: #904 - ci: workaround for CI on linux
Author: mato533
URL: https://github.com/webdriverio-community/wdio-electron-service/pull/904
--------------------------------------------------------------------------------
✔ Do you want to backport this PR? Yes, I want to backport this PR.
Backporting sha 94bb9daa9ff24fce172f3fdf6d99ede98984a91e from v8 to v7
> git cherry-pick -x -m 1 94bb9daa9ff24fce172f3fdf6d99ede98984a91e
[v7 f5b1393] Merge pull request #904 from webdriverio-community/sm/ci-fix-linux
 Date: Fri Jan 24 10:24:30 2025 +0900
 1 file changed, 3 insertions(+)

================================================================================
PR: #908 - ci: add support to release multiple versions
Author: mato533
URL: https://github.com/webdriverio-community/wdio-electron-service/pull/908
--------------------------------------------------------------------------------
✔ Do you want to backport this PR? Yes, I want to backport this PR.
Backporting sha 7976224f74bd57ebafa38819d05ac4f937c957fe from v8 to v7
> git cherry-pick -x -m 1 7976224f74bd57ebafa38819d05ac4f937c957fe
[v7 bef1b08] Merge pull request #908 from webdriverio-community/sm/ci-release
 Author: goosewobbler <[email protected]>
 Date: Wed Jan 29 00:13:14 2025 +0000
 2 files changed, 15 insertions(+), 3 deletions(-)

Successfully backported 2 PRs 👏!
Please now push them to v7 and make a new v7.x release!