Problem Statement

The current behavior with --packageManager yarn defaults to using yarn --silent workspaces info which no longer exists/works with yarn berry (2.0 +). This breaks when adopting the one-version rule in yarn berry monorepos.

Proposed Solution

Introduce a berry packageManager option, that uses yarn workspaces list --json to determine the workspaces in the repo!

Alternatives Considered

Have the default behavior of --packageManager yarn assume yarn berry only and not yarn v1, but this seems overly restrictive if teams want to adopt this package in yarn v1 monorepos.

Additional Context

No response

What

Add an .npmignore or files config to remove extraneous files from the published package

Why

To have the published package be as small as possible

Problem Statement

We have a growing monorepo and are opting for a versioning strategy of pinning all workspace dependencies to exact versions. This makes it clear exactly what version of a dependency a package is using and also during upgrades what the new version is without needing to consult the lockfile or use package manager commands (yarn why). We would like to enforce this versioning strategy in CI and it seems like it might be a good fit/complement to the one version verification.

One note is that it is generally better to opt for ranges with libraries but we are not publishing libraries from this monorepo and are using the one version rule to keep versions consistent between apps and libraries.

Proposed Solution

I think the version strategy could be configured in the one-version.config.json config file. Also open to suggestions on format here:

{
  "versionStrategy": "exact" // or "range", etc
}

In the case you need to opt out of the version strategy in extenuating circumstances, we can allow overrides:

{
  "versionStrategy": {
    "type": "exact",
    "overrides": ["react"] // Allow React to be a range
  }
}

While we could allow per-package overrides I think this conflicts with the goal of the one version rule in general (keeping versioning consistent across all packages in the monorepo).

The version strategy would then be validated during the one version check (one-version check). For the exact version strategy we would error on the baz dependency in the following package:

{
  "name": "foo",
  "dependencies": {
    "bar": "1.2.3",
    "baz": "^1"
  }
}

Alternatives Considered

We've presently implemented this validation as a standalone script run as a separate step in CI, but thought it might make a good addition here.

Additional Context

No response

Before releasing v1, complete the following:

• #7
• #6
• #5
• #9

Problem Statement

Before moving an existing application into a monorepo there's no automated way to check if the dependencies in the application will align with the existing dependency versions in the monorepo or if they'll cause the one-version check to fail.

Proposed Solution

Add a -f --file option to the one-version check command where we can pass an arbitrary (local) file path to check for one-version compatibility.

For example:

yarn one-version check -f /path/to/my/other/repo/package.json

This would allow us to preview the output as if we had already moved the new package.json into the monorepo.

Alternatives Considered

Manually move a package.json into the monorepo and run yarn one-version check to see which versions do not match.

Additional Context

No response

Why

The release process is currently manual and triggered by creating a GH release tag, which kicks off an action to publish the npm package. Before this occurs, someone must update the version in package.json and update the changelog.

What

• Document the release process

Automate as much of process as we can, including potentially:

• Write a script that prompts user with semver version bump & automatically copies [Unreleased] section of changelog into a new section that matches the updated version
• Checking the merged pr for changes to the pjson version, and automating kicking off the release & tagging process from the main pipeline instead of manual release action

Why

Updating all the manifest's in a monorepo is really time consuming and annoying, we should make it faster

What

Add a set/update option to the one version rule script that will update all the pjson's (and lockfile if necessary) in the repo

Possible implementation

When update is selected, require any number of --dep and --version flags, i.e.

• pnpm run one-version update --dep react --version ^16
• pnpm run one-version update --dep react --version ^18 --dep react-dom --version ^18

I initially thought we should have a fix command, but I think it would be difficult to determine what needs changing to "fix" something (i.e. if someone introduced an upgraded dependency, is the fix to downgrade it to match the rest of the repo, or to upgrade the rest of the repo?).

An update/set command could serve both purposes, since it would allow for easy mass-upgrades and "fixing" of single issues as well.

We could also make the script interactive, and prompt users for dependencies and versions 🤔

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update minor packages (eslint, jest, markdownlint-cli, yarn)
• chore(deps): update dependency eslint to v9
• chore(deps): update suzuki-shunsuke/github-action-renovate-config-validator action to v1
• chore(deps): update yarn to v4
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update actions/stale action to v9
• chore(deps): update dependency prettier to v3
• chore(deps): update js-devtools/npm-publish action to v3
• fix(deps): update dependency chalk to v5
• fix(deps): update dependency commander to v12

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Upgrade to Node 16 or newer!

Node 14 is end-of-life, and 16 will become end of life in Sept 2023.

Upgrade node in engines config & ci to latest version allowed by all dependencies. Ensure all tests pass in CI.

Benefit:

Future contributors know how to make a new release (and publish to NPM) when necessary

Deliverable:

Add a section to the Contributing guidelines for how the release workflow works

Current Behavior

The rule currently only evaluates version specifiers across a workspace. This is sufficient for yarn workspaces, but is not for pnpm, as described here.

pnpm workspaces do not have a flat lockfile, so the following is possible:

apps/workspace-a:
  specifiers:
     '@wayfair/ui': ^8
  dependencies:
    '@wayfair/ui': 8.0.0_66b146768d72279e63e637aae37792af

apps/workspace-b:
  specifiers:
     '@wayfair/ui': ^8
  dependencies:
    '@wayfair/ui': 8.0.1_b88fe22cf250f8fb4b578ded3c75a78e

The rule currently passes in the above scenario.

Expected Behavior

The check should fail in the above scenario, by checking the lockfile as well as the manifest specifiers.

Description

👋 This repository is not currently configured for Renovate. This issue proposes the steps necessary to add Renovate to this project!

💡 Not familiar with Renovate, or are confused about what advantages it holds over GitHub's Dependabot? Learn more here!

Steps to Add

1. Review the guide for Adding Renovate to Existing Projects.
2. Assign yourself to this issue to signal to others that you intend to work on it. If you ultimately decide not to pursue this, please remember to un-assign yourself so that others may participate!
3. The renovate[bot] account has already auto-filed a Configure Renovate PR against this repository, feel free to reference the proposed changes in your own Pull Request. If you are contributing to this project as a Hacktoberfest participant, you must file your own PR in order to get credit for your contribution!
4. You may find that the CI build for this project is failing for unrelated reasons. If you are not already a contributor to this project and don't feel comfortable attempting to fix the build, that's okay! There's plenty of other ways you can contribute to Wayfair's open source projects :) Feel free to consult the list of our other participating repositories here!
5. In order to catch potential JSON syntax errors or other mis-configurations, please add Renovate linting to this project's existing GitHub Workflow CI pipeline, or create a new one (eg. .github/workflows/lint.yml). See here for an example.
6. If this repository is currently configured to use GitHub's Dependabot, you must also deprecate support for Dependabot in order to avoid conflicts with Renovate. This is typically as simple as removing the .github/dependabot.yml file. See here for an example.

Checklist

• I have read the Adding Renovate to Existing Projects guide.
• I have assigned this issue to myself avoid duplicating efforts with other potential contributors.
• I have verified this repository does not already have Renovate configured (or proposed in an open PR by another contributor).
• If the renovate[bot] account has already auto-filed a Configure Renovate PR in this repository, I confirm that I will create a separate PR under my own GitHub account, using the initial PR as inspiration.
• I confirm that I have added Renovate linting to this project's existing CI pipeline, or have created a new linting workflow if one doesn't already exist.
• If this repository is currently configured to use GitHub's Dependabot, my PR will also deprecate support for Dependabot in order to avoid conflicts with Renovate.

What

Add a packageManager field to the one-version.config.json configuration.

Merge this configuration option with the -p, --packageManager flag passed directly to the command. Determine & document which should take precedence.

Why

Make it easier for folks to configure the package manager in a single place, instead of passing it as an option to every command.