Skip to content

Decouple dump warning flags for env-label fallback#25

Merged
justin808 merged 2 commits intomainfrom
jg/fix-23
Apr 3, 2026
Merged

Decouple dump warning flags for env-label fallback#25
justin808 merged 2 commits intomainfrom
jg/fix-23

Conversation

@justin808
Copy link
Copy Markdown
Member

@justin808 justin808 commented Apr 2, 2026

Summary

  • Decouple dump warning controls so --no-warn-sensitive only suppresses sensitive-output warnings.
  • Add --no-warn-env-label to suppress the build-matrix NODE_ENV fallback environment-label note.
  • Update CLI integration tests and docs (README, CLI reference, changelog) to reflect the new semantics.

Closes #23.

Testing

  • npm test -- --runInBand
  • npm run build

Note

Low Risk
Low risk: changes are limited to CLI warning/flag behavior in dump (new flag and adjusted gating), with updated docs and integration tests; main functional impact is on stderr output for build-matrix runs.

Overview
Decouples dump warning controls so --no-warn-sensitive suppresses only the sensitive-output warning, and introduces --no-warn-env-label to independently silence the build-matrix note when the environment label falls back to build.environment.NODE_ENV.

Updates CLI help text, README/CLI reference, changelog, and expands integration tests to verify the two warnings can be enabled/suppressed independently.

Written by Cursor Bugbot for commit f0d0c0f. This will update automatically on new commits. Configure here.

Summary by CodeRabbit

  • New Features

    • Added a --no-warn-env-label flag to suppress environment-label warnings in dump output.
  • Changed

    • --no-warn-sensitive now suppresses only sensitive-output warnings; environment-label notes are controlled separately.
  • Documentation

    • CLI reference and README updated with --no-warn-env-label docs and examples.
  • Tests

    • Expanded CLI integration tests to validate independent suppression behavior of both warning flags.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 2, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 5b22e797-147a-468a-ab3f-08d71f80a379

📥 Commits

Reviewing files that changed from the base of the PR and between cc9f325 and f0d0c0f.

📒 Files selected for processing (2)
  • src/cli.ts
  • test/cli.integration.test.js
🚧 Files skipped from review as they are similar to previous changes (2)
  • src/cli.ts
  • test/cli.integration.test.js

Walkthrough

This PR decouples two dump warnings by adding a new --no-warn-env-label CLI flag to suppress only the build-matrix NODE_ENV fallback-label note; --no-warn-sensitive now suppresses only the sensitive-output warning. Implementation, docs, and integration tests were updated to reflect this behavior.

Changes

Cohort / File(s) Summary
Documentation
CHANGELOG.md, README.md, docs/cli-reference.md
Added docs and examples for the new --no-warn-env-label flag and clarified that --no-warn-sensitive only affects sensitive-output warnings.
CLI Implementation
src/cli.ts
Added warnEnvLabel parsed option (default true) with --no-warn-env-label to toggle environment-label notes; warning print for build NODE_ENV label now gated by warnEnvLabel instead of warnSensitive.
Integration Tests
test/cli.integration.test.js
Replaced prior test with focused cases validating: default emits env-label note; --no-warn-sensitive suppresses only sensitive warning; --no-warn-env-label suppresses only env-label note; both flags together suppress both warnings.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I sniffed the flags beneath the log,
Two warnings tangled in a fog.
One hop, one flag to set them free,
Now each warning minds its own decree.
Happy hops for clearer CLI! 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Decouple dump warning flags for env-label fallback' accurately summarizes the main change—introducing independent warning controls for sensitive output and environment-label notes.
Linked Issues check ✅ Passed The PR fully addresses issue #23's acceptance criteria: CLI option semantics are clear (--no-warn-sensitive suppresses sensitive warnings; --no-warn-env-label suppresses env-label notes), help text and docs are updated, and integration tests cover all warning combinations.
Out of Scope Changes check ✅ Passed All changes are scoped to implementing independent warning controls as specified in issue #23: CLI flag parsing, warning logic, documentation, and integration tests.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch jg/fix-23

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Comment thread test/cli.integration.test.js
Comment thread src/cli.ts
Comment thread test/cli.integration.test.js
@claude
Copy link
Copy Markdown

claude Bot commented Apr 2, 2026

Review: Decouple dump warning flags for env-label fallback

The core change is correct and well-scoped. The one-line fix in runDumpFromBuildConfig (swapping warnSensitivewarnEnvLabel for the NODE_ENV label note) is exactly right, and the new tests properly verify the decoupled behavior in both directions.

Things that look good

  • Logic change is minimal and accurate — the guard at line 750 now references the right flag; warnSensitive still correctly gates the sensitive-output warning for all dump modes via the earlier check at line 865.
  • Docs are complete — CHANGELOG, README, and CLI reference are all updated and clearly describe what each flag does and does not suppress.
  • New tests cover the key cases — default warns, --no-warn-sensitive keeps the label note, --no-warn-env-label suppresses it while keeping the sensitive warning.

Minor issues (see inline comments)

  1. Test fixture duplication — the three new tests write identical files. A small shared helper would reduce ~30 lines of duplication and is worth doing before the PR merges.
  2. --no-warn-env-label silently no-ops outside build-matrix context — worth either documenting in help text or validating at parse time so users don't accidentally use the flag on a single-file dump and wonder why it had no effect.
  3. No combined-flag test — a test for --no-warn-sensitive --no-warn-env-label together would close out coverage and guard against future regressions where one flag inadvertently re-enables the other.

None of these are blockers, but items 1 and 3 are easy fixes before merge.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
test/cli.integration.test.js (1)

490-560: Optional: extract shared build-fixture setup to reduce repetition.

The duplicated temp config/build YAML setup across these tests could be moved to a small helper for easier maintenance.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@test/cli.integration.test.js` around lines 490 - 560, Multiple tests (the
"dump --build warns when metadata environment label falls back to build
NODE_ENV", "dump --build --no-warn-sensitive keeps NODE_ENV label note", and
"dump --build --no-warn-env-label suppresses NODE_ENV label note") repeat the
same temp file setup using configPath, buildConfig and fs.writeFileSync; extract
that repeated logic into a small helper (e.g., createBuildFixture or
writeBuildBuildConfig) that takes tempDir, webpack contents and environment
values and returns the configPath and buildConfig, then replace the repeated
fs.writeFileSync/variable assignments in each test and use the helper before
calling run and checking errorSpy. Ensure the helper is imported/defined near
the top of test/cli.integration.test.js and referenced by the existing test
functions (run, configPath, buildConfig, errorSpy remain unchanged in
assertions).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@test/cli.integration.test.js`:
- Around line 490-560: Multiple tests (the "dump --build warns when metadata
environment label falls back to build NODE_ENV", "dump --build
--no-warn-sensitive keeps NODE_ENV label note", and "dump --build
--no-warn-env-label suppresses NODE_ENV label note") repeat the same temp file
setup using configPath, buildConfig and fs.writeFileSync; extract that repeated
logic into a small helper (e.g., createBuildFixture or writeBuildBuildConfig)
that takes tempDir, webpack contents and environment values and returns the
configPath and buildConfig, then replace the repeated fs.writeFileSync/variable
assignments in each test and use the helper before calling run and checking
errorSpy. Ensure the helper is imported/defined near the top of
test/cli.integration.test.js and referenced by the existing test functions (run,
configPath, buildConfig, errorSpy remain unchanged in assertions).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8ba635a2-92e8-4062-a983-9926fda6d271

📥 Commits

Reviewing files that changed from the base of the PR and between ddee4d4 and cc9f325.

📒 Files selected for processing (5)
  • CHANGELOG.md
  • README.md
  • docs/cli-reference.md
  • src/cli.ts
  • test/cli.integration.test.js

- Add test verifying --no-warn-sensitive and --no-warn-env-label work
  independently when used together
- Clarify in help text that --no-warn-env-label only applies in
  build-matrix mode and is ignored for single-file dumps

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Comment thread CHANGELOG.md

### Changed

- Decoupled dump warning controls: `--no-warn-sensitive` now only suppresses sensitive-output warnings, and new `--no-warn-env-label` suppresses build-matrix `NODE_ENV` environment-label notes. [Issue #23](https://github.com/shakacode/pack-config-diff/issues/23)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The behavioral change to --no-warn-sensitive is a breaking change for any existing automation that relied on the old coupling (using --no-warn-sensitive in build-matrix mode previously suppressed the NODE_ENV label note too). The current entry only describes the new semantics without warning existing users about the migration impact.

Consider calling this out more explicitly, e.g.:

Suggested change
- Decoupled dump warning controls: `--no-warn-sensitive` now only suppresses sensitive-output warnings, and new `--no-warn-env-label` suppresses build-matrix `NODE_ENV` environment-label notes. [Issue #23](https://github.com/shakacode/pack-config-diff/issues/23)
- **Breaking:** `--no-warn-sensitive` now only suppresses sensitive-output warnings; it no longer silences the build-matrix `NODE_ENV` environment-label note. Migrate any scripts using `--no-warn-sensitive` to suppress both by adding `--no-warn-env-label`. New `--no-warn-env-label` flag suppresses only the environment-label note independently. [Issue #23](https://github.com/shakacode/pack-config-diff/issues/23)

Comment thread src/cli.ts
const resolvedEnvironment = resolveBuildEnvironmentLabel(build, parsed);
const envLabel = resolvedEnvironment.label;
if (resolvedEnvironment.source === "build-node-env" && parsed.warnSensitive) {
if (resolvedEnvironment.source === "build-node-env" && parsed.warnEnvLabel) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is the core behavioral change and warrants a comment explaining the intentional decoupling, especially since the old gate used warnSensitive here. Future readers seeing this alongside the warnSensitive check at line 865 may wonder whether the different field is a bug or intentional.

Suggested change
if (resolvedEnvironment.source === "build-node-env" && parsed.warnEnvLabel) {
if (resolvedEnvironment.source === "build-node-env" && parsed.warnEnvLabel) {
// Intentionally uses warnEnvLabel (not warnSensitive) — these warnings are independent.
// --no-warn-env-label suppresses only this note; --no-warn-sensitive suppresses only
// the sensitive-output warning shown when --clean is omitted.

Comment on lines 491 to 505
@@ -504,33 +504,109 @@ describe("CLI integration", () => {
"utf8",
);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same configPath/buildConfig setup block (lines 491–505 here) is copy-pasted verbatim in all four new tests. Since tempDir is already shared via beforeEach, this can be pulled into its own beforeEach block (or a helper) within a nested describe grouping for these build-matrix warning tests.

Duplication isn't a correctness bug, but it adds friction when the fixture needs to change — currently you'd have to update it in four places.

Comment thread src/cli.ts
--env=<KEY=VALUE> Set env var before loading config (repeatable)
--clean Strip plugin internals and compact functions before dump (recommended for secrets safety)
--no-warn-sensitive Suppress the sensitive-output warning when running dump without --clean
--no-warn-env-label Suppress the build NODE_ENV environment-label note (only applies in build-matrix mode; ignored for single-file dump)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The help text documents that --no-warn-env-label is "ignored for single-file dump", but there's no test covering that case and no user-visible feedback when the flag is silently ignored. A test asserting exit code 0 with a note in stderr (or simply asserting no crash) would confirm the documented behaviour and prevent silent regressions.

@claude
Copy link
Copy Markdown

claude Bot commented Apr 3, 2026

Code Review

The decoupling approach is clean and the implementation is correct. Four observations:

Breaking change needs clearer signposting (CHANGELOG.md:17)
Before this PR, --no-warn-sensitive in build-matrix mode suppressed both the sensitive-output warning and the NODE_ENV label note. Any existing automation relying on that behaviour will silently start emitting the label note after upgrading. The CHANGELOG entry describes the new semantics but does not flag the migration step. Suggest a Breaking Changes section or an explicit migration note.

Clarifying comment missing at the decoupling point (src/cli.ts:750)
The line changed from parsed.warnSensitive to parsed.warnEnvLabel. Without a short comment, future readers could mistake this for a copy-paste error given the parallel warnSensitive check at line 865.

Test fixture duplicated four times (test/cli.integration.test.js:491-505)
The configPath/buildConfig write block is copy-pasted verbatim across all four new tests. A nested describe with a beforeEach would reduce maintenance surface.

No test for the documented single-file no-op (src/cli.ts:115)
The help text says --no-warn-env-label is ignored for single-file dumps, but there is no test coverage for this path.


Overall the feature is well-scoped and the independent-flag test coverage is good. Main ask is making the breaking behaviour change explicit for upgraders.

@justin808 justin808 merged commit 06da48b into main Apr 3, 2026
24 checks passed
@justin808 justin808 deleted the jg/fix-23 branch April 3, 2026 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Follow-up: clarify --no-warn-sensitive vs env-label warning semantics

1 participant