# @govuk-one-login/frontend-logger

> Shared logger for one-login-frontend packages

Latest version **0.0.2** (published 2026-05-11) · ISC license · 0 weekly downloads

## Install

```sh
npm install @govuk-one-login/frontend-logger
pnpm add @govuk-one-login/frontend-logger
yarn add @govuk-one-login/frontend-logger
bun add @govuk-one-login/frontend-logger
```

## Health

**Score 65/100 (B)** — status: active.

Positive: has types; esm support; no vulnerabilities; has provenance; high quality score.

Warnings: low downloads; pre 1.0.

## Facts

| | |
|---|---|
| Version | 0.0.2 |
| Published | 2026-05-11 |
| First published | 2026-05-11 |
| Weekly downloads | 0 |
| License | ISC |
| TypeScript types | bundled |
| Module format | ESM + CommonJS |
| Dependencies | 0 |
| Unpacked size | 66 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Provenance | attested (GitHub Actions) |
| Author | DI Frontend Capability Team |
| Maintainers | pcornishgds, nickheal-gds, merlinc, wilsondrrn, sambunce-gds, danielmason-gds, alexws-gds, dancorder, ug-gds, davidmcmichaelgovuk, mike.beeby |
| Keywords | govuk-one-login, gds, govuk-onelogin, govuk one login |

## Links

- npm: https://www.npmjs.com/package/@govuk-one-login/frontend-logger
- Repository: https://github.com/govuk-one-login/govuk-one-login-frontend
- Homepage: https://github.com/govuk-one-login/govuk-one-login-frontend#readme
- Issues: https://github.com/govuk-one-login/govuk-one-login-frontend/issues
- npm.io page: https://npm.io/package/@govuk-one-login/frontend-logger

## Alternatives

- [cli-color](https://npm.io/package/cli-color.md) — 3.4M weekly downloads
- [log](https://npm.io/package/log.md) — 1.3M weekly downloads
- [logstash-client](https://npm.io/package/logstash-client.md) — 4.5K weekly downloads
- [@nocobase/plugin-logger](https://npm.io/package/@nocobase/plugin-logger.md) — 2.0K weekly downloads
- [child-process-debug](https://npm.io/package/child-process-debug.md) — 695 weekly downloads

## Recent versions

- 0.0.2 (latest) — 2026-05-11
- 0.0.1 — 2026-05-11

## README

# GovUK Frontend Monorepo

This monorepo is designed to house packages and UI components based on the GOV.UK Frontend design system. It utilises the Nx workspace for managing multiple projects within a single repository.

## Features

- Nx workspace setup for efficient development and collaboration.
- Integration of GovUK Frontend packages and UI components.
- Simplified build and deployment processes.
- Consistent coding standards and best practices set out in the GDS way https://gds-way.digital.cabinet-office.gov.uk/standards

## Project Structure

The monorepo is organised using Nx workspace conventions

## Continuous Deployment (CD) Workflow

To trigger the CD workflow manually, follow these steps:

- Go to the Actions tab in this repository.
- Click on the "CD" workflow.
- Click the "Run workflow" button.
- Select the target package and the desired increment type.
- Click the "Run workflow" button to start the deployment process.

# Getting started

> At present we consume one package from a private registry (@govuk-one-login/event-catalogue). To authenticate with GitHub Packages to get this package you should follow [the instructions in the team manual](https://team-manual.account.gov.uk/development-standards-processes/coding-practices-and-processes/configure-node-package-managers/#configuring-node-package-managers).

To get started in this repository we recommned you:
1. Run `npm install` to get all the neccessary dependencies.
2. Run `npm run prepare-dependencies` to prepare any dependencies that were broken by disabling npm lifecycle scripts.
3. Run `npm run build` to build all dependencies so that interlinked packages work.

# Create A New Package

To create a new package, follow these steps:

- Run the following command:

  ```bash
  nx g automation:generate-component
  ```

  Or, if you want to specify the package name, run:

  ```bash
  nx g automation:generate-component package-name
  ```

- The NX prompt will ask you the following questions:

  - **Name**: What name would you like to use? (required)
  - **Description**: What is the package about? (optional)

- Answer the prompts accordingly. If you provided the package name in the command, you won't be asked for it.

- After answering the questions, the command will generate the package with the necessary files.

## Lint and format the code with Biome:

This project uses [Biome](https://biomejs.dev/) for linting and formatting. Biome replaces ESLint and Prettier with a single fast tool.

### To Run All Packages

To check linting and formatting issues in all packages:
`nx run-many --target=lint --all`

To check code formatting in all packages:
`nx run-many --target=format:check --all`

To fix formatting issues that can be resolved automatically:
`nx run-many --target=format --all`

To run a full check (lint + format + import sorting) and auto-fix:
`npm run check:fix`

To run the above commands on just affected packages, replace `run-many` with `affected`

### To Run a Singular Package

To check lint issues in a specific package:
`nx run [package-name]:lint`

To check and fix code formatting issues in a specific package:
`nx run [package-name]:format`

### Configuration

The rules for linting and formatting are defined in `biome.json` at the root of the repository. Biome uses a single configuration file for both linting and formatting.

### Editor Integration

Install the [Biome VS Code extension](https://marketplace.visualstudio.com/items?itemName=biomejs.biome) for format-on-save and inline lint diagnostics.

## Setup Instructions

To ensure that NX is running the latest versions of all packages within the monorepository, follow these steps:

### At the Root Level:
1. Install dependencies by running `npm install`.
2. Build the entire project by running `npm run build`.

### At the `alpha-app` Level:
1. Start the development server by running `npm run dev`.
   This will automatically refresh the symlink as part of the watch command, ensuring that changes to linked packages are up-to-date.

### At the `frontend-language-toggle` Level:
1. Start the development process by running `npm run dev`.
2. Ensure that this package is running alongside the `dev` command to reflect updates properly.

## Running `alpha-app`

1. `npm run build` at the root
2. `npm run start` in `alpha-app`
3. The app should be running on `localhost:3000`

## Publishing Packages

To release a package from the monorepo, use the **GitHub Actions Release workflow**. This workflow automates versioning and package publishing to NPM. Follow these steps to initiate a release:

1. **Trigger the Workflow**  
   Go to the **Actions** tab in the GitHub repository, select the **Release** workflow, and click **Run workflow**.

2. **Fill in the Required Inputs**:
   - **Target**: Choose the package you want to release from the list of options:
     - `@govuk-one-login/alpha-component`
     - `@govuk-one-login/frontend-analytics`
     - `@govuk-one-login/frontend-language-toggle`
     - `@govuk-one-login/frontend-passthrough-headers`
     - `@govuk-one-login/frontend-vital-signs`
     - `@govuk-one-login/frontend-asset-loader`
     - `@govuk-one-login/frontend-device-intelligence`
   - **Increment**: Select the version increment for this release (`patch`, `minor`, or `major`) based on [Semantic Versioning](https://semver.org/).
   - **First Release**: Specify if this is the first release of the package from this repository. If set to `true`, the workflow will treat it as an initial release.
   - **Dry Run**: Set this to `true` for a dry run, which will simulate the release process without publishing.

3. **Publishing Process**  
   The workflow will:
   - Run format, lint, test, and build checks on the specified package.
   - Automatically version and publish the package to NPM if the `dry_run` is set to `false`.

4. **Verify the Release**  
   Once the workflow completes, confirm the package has been published on the NPM registry.

## Maintaining Older Package Versions

When releasing a new major version of a package (e.g., `frontend-ui` v5 → v6), you need to maintain the ability to patch the older version for consumers who haven't upgraded yet. This is done using **version branches**.

### Branch Naming Convention

Version branches follow the format: `{package-name}@v{major-version}`

Examples:
- `frontend-ui@v1` — maintains v1.x.x of `@govuk-one-login/frontend-ui`
- `frontend-analytics@v2` — maintains v2.x.x of `@govuk-one-login/frontend-analytics`

### When to Create a Version Branch

Create a version branch **before releasing a new major version**. For example, if `frontend-ui` is currently on v5.3.2 and you're about to release v6.0.0:

1. Create the version branch from the current state of `main` (or from the last release tag):
   ```bash
   git checkout main
   git checkout -b frontend-ui@v5
   git push -u origin frontend-ui@v5
   ```
2. Proceed with the major version release from `main`.

### Releasing a Patch from a Version Branch

1. Create a feature branch from the version branch:
   ```bash
   git checkout frontend-ui@v5
   git checkout -b fix/ticket-number/description
   ```
2. Make your changes and push the feature branch.
3. Open a PR targeting the version branch (e.g., `frontend-ui@v5`), **not** `main`.
4. Get the required review approval and wait for status checks to pass.
5. Merge the PR.
6. Go to **Actions** → **Release** → **Run workflow**.
7. Select the version branch (e.g., `frontend-ui@v5`) from the branch dropdown.
8. Choose the target package and set increment to `patch`.
9. Run the workflow — this will publish the patch release from the version branch.

### Branch Protections

Version branches have the same protections as `main`:
- Pull requests are required (minimum 1 approving review)
- Status checks must pass before merging
- Force pushes are blocked
- Branch deletion is blocked

See [`docs/version-branch-ruleset-setup.md`](docs/version-branch-ruleset-setup.md) for details on how the repository ruleset is configured.

## Releasing on Alternative Channels

Sometimes you need to release a pre-release or alternative-channel version of a package — for example, a release candidate (`rc`) or a beta — without affecting consumers on the `latest` npm tag. This is done using **channel branches**.

### Channel Branch Naming Convention

Channel branches follow the format: `{package-name}@v{version}/{channel-name}`

Examples:
- `frontend-analytics@v1.0.0/rc` — release candidate channel for `@govuk-one-login/frontend-analytics`
- `frontend-ui@v5.2.0/beta` — beta channel for `@govuk-one-login/frontend-ui`

### When to Use a Channel Branch

Use a channel branch when you need to:
- Publish a release candidate for testing before a full release
- Provide a hotfix to specific consumers without promoting it to `latest`
- Test a package change in a production-like environment before general availability

### Creating a Channel Branch and Releasing

1. Create the channel branch from the appropriate base (e.g., `main` or a version branch):
   ```bash
   git checkout main
   git checkout -b frontend-analytics@v1.0.0/rc
   git push -u origin frontend-analytics@v1.0.0/rc
   ```

2. Create a feature branch from the channel branch for your changes:
   ```bash
   git checkout frontend-analytics@v1.0.0/rc
   git checkout -b fix/ticket-number/description
   ```

3. Make your changes and push the feature branch.

4. Open a PR targeting the channel branch (e.g., `frontend-analytics@v1.0.0/rc`), **not** `main`.

5. Get the required review approval and wait for status checks to pass.

6. Merge the PR.

7. Go to **Actions** → **Release** → **Run workflow**.

8. Select the channel branch (e.g., `frontend-analytics@v1.0.0/rc`) from the branch dropdown.

9. Choose the target package. The **increment** input is ignored for channel branches — the workflow automatically detects the channel name from the branch and produces a prerelease version (e.g., `1.0.0-rc.0`, `1.0.0-rc.1`, etc.).

10. Run the workflow — this will publish a prerelease version to npm.

### Installing a Channel Release

Consumers can install a specific prerelease version:
```bash
npm install @govuk-one-login/frontend-analytics@1.0.0-rc.0
```

### Channel Branch Protections

Channel branches have the same protections as `main` and version branches:
- Pull requests are required (minimum 1 approving review)
- Status checks must pass before merging
- Force pushes are blocked
- Branch deletion is blocked

See [`docs/version-branch-ruleset-setup.md`](docs/version-branch-ruleset-setup.md) for details on how the repository ruleset is configured.

## Deprecating Packages

To deprecate a specific package version from the monorepo, use the **GitHub Actions Deprecate workflow**. This workflow automates deprecating packages in NPM:

1. **Trigger the Workflow**
   Go to the **Actions** tab in the GitHub repository, select the **Deprecate** workflow, and click **Run workflow**.

2. **Fill in the Required Inputs**:
   - **Target**: Choose the package you want to release from the list of options:
     - `@govuk-one-login/alpha-component`
     - `@govuk-one-login/event-catalogue-utils`
     - `@govuk-one-login/frontend-analytics`
     - `@govuk-one-login/frontend-language-toggle`
     - `@govuk-one-login/frontend-passthrough-headers`
     - `@govuk-one-login/frontend-vital-signs`
     - `@govuk-one-login/frontend-asset-loader`
     - `@govuk-one-login/frontend-ui`
     - `@govuk-one-login/frontend-device-intelligence`
     - `@govuk-one-login/frontend-logger`
   - **Version**: Enter the version you want to deprecate (eg `0.0.1`, `0.1.1`, `1.0.1`)

3. **Deprecation Process**
   The workflow will automatically run the `npm deprecate` command with the input values you have selected.

4. **Verify the Deprecated**
   Once the workflow completes, confirm the package has been deprecated on the NPM registry with an appropriate message.

## How to Run Performance Tests 

To run performance tests using k6, follow these steps:

- Head over to the alpha app and run it in product mode
- Change the end-point in the alpha app to `test-submit-button`
- Run the command `k6 run testServer.js` if you have K6 installed otherwise run `npm run test:server`

## Contributing Code

We welcome contributions from other teams to the **govuk-one-login-frontend** monorepo! Follow these guidelines to ensure consistency and quality across the repository.

### Steps to Contribute

1. **Clone The Repo**  

   Clone the repository locally and navigate into the project directory:
   ```bash
   git clone git@github.com:govuk-one-login/govuk-one-login-frontend.git ./your_folder_name

  Replace your_folder_name with your desired directory name. If you omit this part, it will clone into a folder named govuk-one-login-frontend.

2. **Creating A Branch**

After cloning, create a new branch with a descriptive name that reflects the changes you’re making. For example:

 `git checkout -b ticket-number/your-feature-name`

3. **Install Dependencies**

Ensure all dependencies are installed, by running:

  `npm install`

4. **Make Your Changes**

Add your code changes, ensuring that they align with GOV.UK OneLogin coding standards and best practices.

5. **Run Tests and Linting**

Before pushing your changes, run all tests and linting to make sure your code adheres to the monorepo's requirements:

- If you only want to run tests in the affected package, `cd` into the package folder and run `npm test` or just `npm test` at the root level to run all test suites.
- If there are any uncommitted changes, you will need to run `npx nx run-many -t test` as the tests and linters cache the results, so they will only run for changed cases.

- [Lint and format the code with Biome:](#lint-and-format-the-code-with-biome)

6. **Commit and Push Changes**

Use **Conventional Commits** for your commit messages to ensure automatic versioning and changelog updates. This allows NX to automatically generate a changelog with merged PRs for each release, helping users track the latest changes when they update their packages.

For example:

- `feat(ticket-number): add new component for user authentication`
- `fix(ticket-number): correct header alignment issue`
- `docs(ticket-number): update README with contribution guidelines`


When pushing commits, avoid `git push -f` to prevent overwriting others' changes. Use `git push --force-with-lease` to ensure remote changes aren’t accidentally overwritten.

We also encourage squashing each merge to main using conventional commits. This keeps the git log clean and organised.

7. **Open a Pull Request**

We use a PR template to ensure all necessary details are captured. Simply fill in the details and check the relevant checkboxes. 

8. **Review and Approval**

Your PR needs to be reviewed by a member of the code owners, the digital-identity-frontend-capability team. Once approved can be merged into main, but the branch should not be deleted.

## Useful Links

- [The GDS Way](https://gds-way.digital.cabinet-office.gov.uk/)
- [GOV.UK Design System](https://design-system.service.gov.uk/)
- [The Frontend Capability Team's Coding Standards](https://govukverify.atlassian.net/wiki/spaces/DIFC/pages/3779199166/Coding+Standards)

---
_Source: https://npm.io/package/@govuk-one-login/frontend-logger · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._