Detect New Library Pro

The detect-new-library command scans pubspec.yaml files changed in a pull request and reports any newly added direct dependencies. It is warn-only by default — the intent is visibility, not blocking. Teams can opt into blocking mode once they have established a review culture around new dependency additions.

detect-new-libraryA new dependency shows up in the pull request logNeeds Pro

Step 1 of 4, before: The check compares each changed pubspec.yaml with its copy on the base branch. By default it only reports, so it never blocks a merge.

my_workspace

$ 

features/home/home_impl/pubspec.yaml

dependencies:  # …  home_api:    path: ../home_api  locale_core:    path: ../../../shared/locale_core  # …

.newlibrary.yaml

# detect-new-library configurationfail_on_new: falseignored_packages:  - flutter  - dart

Usage

# Report-only (default, always exits 0)
dart run monorepo_toolkit detect-new-library check

# Check against a specific base branch
dart run monorepo_toolkit detect-new-library check --base develop

# Blocking mode (exits 1 if new libraries found)
dart run monorepo_toolkit detect-new-library check --fail

Flags

Flag	Abbr	Default	Description
--base	-b	auto	Base branch to diff against (auto-detected from the CI environment when omitted)
--fail		false	Exit 1 if new direct dependencies are detected (overrides the config file)

Configuration is always read from .newlibrary.yaml at the workspace root.

Configuration

The brick generates .newlibrary.yaml at the workspace root. All keys are top-level:

fail_on_new: false

ignored_packages:
  - flutter
  - dart

# Optional. The --base flag overrides it; without either, the base branch
# is detected from the CI environment.
# base_branch: develop

When ignored_packages is missing, it defaults to flutter and dart. A list you set replaces the default, so keep both entries in it.

Set fail_on_new: true in the config file to permanently enable blocking mode without requiring the --fail flag on every invocation.

Why warn-only by default

New dependencies are not inherently bad — they are often the right choice. The goal of this tool is to make new additions visible in PR reviews so teams can ask the right questions: Is this library maintained? Does an equivalent already exist in the workspace? What is its transitive dependency footprint?

Once a team has established that culture, enabling fail_on_new: true shifts the gate to a mandatory approval step.

CI integration

# Warn-only — always passes, surfaces in CI logs
steps:
  - name: Detect new dependencies
    run: dart run monorepo_toolkit detect-new-library check --base ${{ github.base_ref }}

# Blocking mode
steps:
  - name: Detect new dependencies (blocking)
    run: dart run monorepo_toolkit detect-new-library check --base ${{ github.base_ref }} --fail