v7.0.0

[tanem]

Summary

v7.0.0. Fifteen commits, each with the detail in its own message; the consumer-facing changes are all in MIGRATION.md.

Breaking

• Drops the withNProgress HOC. React's docs treat higher-order components as a legacy pattern, and it was the only consumer of hoist-non-react-statics. The replacement is one line of consumer code.
• Drops the UMD builds. React 19 ships no UMD build of its own, so the script-tag path already only worked with React 18 and earlier.
• Replaces the tsc → Rollup + Babel pipeline with a single tsdown build, and adds an exports map. Output filenames change to dist/react-nprogress.cjs / .mjs with matching .d.cts / .d.mts. Node ESM consumers were resolving to the CommonJS build because Node ignores module; they now get the ES module build. main, module and types stay for webpack 4 and TypeScript node10 resolution.
• Drops the separate development and production CommonJS builds. They differed only by minification, which bundlers apply themselves, so process.env.NODE_ENV is no longer read at require time.
• Drops @babel/runtime. The package now has no runtime dependencies, only peers.

Fixes

• Fixes two StrictMode bugs. Mounted under StrictMode, useNProgress() with isAnimating: false animated straight to progress: 1, and useNProgress({ isAnimating: true }) reported { isFinished: true, progress: 0 } instead of starting. Both came from useUpdateEffect, whose first-mount ref is flipped during render, so StrictMode's double-invoked render made the committed render look like an update. The hook is now a { phase, progress } reducer over four phases, gated on the phase rather than on whether this is the first render. That removes the sideEffect-in-state bridge, three hooks vendored from react-use, createQueue and four eslint suppressions. Observable pacing is unchanged: every pre-existing spec passes unedited.
• Fixes two cases where changing an option mid-animation misbehaved, both predating v7. Changing minimum rewound the bar, because start re-ran against an animation already in flight; on the published 6.0.4 the same change reset progress to 0 outright. Changing animationDuration, which the animating phase never reads, cancelled the pending trickle. start is now guarded on the phase the same way complete is, and the timer effect is split per phase so each depends only on the options its own phase reads. Three specs cover it.
• Adds "use client" to the published bundles. Every export is or wraps a hook and the timers run on window.requestAnimationFrame, so importing from a server component now fails at the module boundary rather than with a hooks error at render time.
• Fixes the README Usage snippets, which mounted with render from react-dom, removed in React 19, so the first thing a new user copied threw at runtime.
• Fixes the react-router example, which passed one unattached nodeRef to every CSSTransition, so the bar completed 323ms after a click instead of running for the configured 1200ms. Predates v7: reproduced against the published 6.0.4.
• Makes the app-router example's slow pages render per request. await new Promise(setTimeout) carries no dynamic signal, so Next ran it at build time and both routes shipped static; only next dev behaved as intended.

Additions

• Exports NProgressOptions and NProgressState. Both shapes previously reached the declarations as unnamed local interfaces, so wrapping either entry point meant Parameters<typeof useNProgress>[0]. Type-only, so the runtime bundles are byte-identical.
• Gates the published package shape with publint and arethetypeswrong, as a postbuild hook.
• Asserts what the build emits in test/bundles.spec.ts, run from its own Jest config after the build. Keeping it out of config.src.js leaves npm run test:src and the React matrix runnable on a clean checkout, and stops the bundle assertions repeating once per React version.
• Gates bundle size with size-limit, gzip to match the README badge. Actuals: ESM 1003 B, CJS 1063 B.
• Adds React 19.2 to the test matrix as the current 19 latest minor.
• Runs CI on v* branches. Both filters were limited to master, so v7 ran no CI at all.

Docs

• Restructures the README API section into a table of options with one heading per option, adds a "When to Use This" section, and documents what the old bullets left out: minimum is clamped against the first increment, and isAnimating going false is what drives completion.
• Moves .github/copilot-instructions.md to a root AGENTS.md, read by Claude Code, Copilot, Cursor and Codex. Copilot code review gained root AGENTS.md support in June 2026, so the vendor-specific file is deleted rather than kept as a pointer.

Test plan

• npm test passes: format and type checks, lint, build, publint, arethetypeswrong, size gate, then src, CJS, ESM, bundle and React-matrix specs
• Coverage of src stays at 100%
• CI green on every commit in the branch
• arethetypeswrong reports no problems under node10, node16 (from CJS and ESM) and bundler resolution
• All eight examples clean-installed against a npm pack tarball of this branch and driven in a headless browser: each starts, advances and completes with no console errors
• Both Next examples additionally checked under next build && next start, confirming the CJS entry and the "use client" directive hold on the server
  Labelled breaking, so the Monday release cron derives a major bump.

🤖 Generated with Claude Code

[tanem]

Code review

Found 1 issue:

1. The minimum docs state the opposite of the implemented behaviour. The README says changing minimum mid-animation "restarts the bar from that first increment", but the start reducer case returns the existing state unchanged when state.phase === 'animating', so progress holds. The code comment ("a repeat dispatch against a running animation must not rewind the bar. That happens whenever minimum changes mid-animation") and the test keeps its place when minimum changes mid-animation both confirm the guard.

react-nprogress/README.md

Lines 134 to 137 in 63b1dcf

	#### `minimum`
	Lower bound for `progress`, between `0` and `1`. The first increment starts from `0.1` rather than from `0`, so the bar appears at `max(0.1, minimum)` and the option only shows through when it is set above `0.1`. Changing it while the bar is animating restarts the bar from that first increment.

react-nprogress/src/useNProgress.tsx

Lines 52 to 62 in 63b1dcf

	//
	// Guarded the same way as `complete`, and for the same reason: a repeat
	// dispatch against a running animation must not rewind the bar. That
	// happens whenever `minimum` changes mid-animation, as well as on a
	// StrictMode double-mount.
	return state.phase === 'animating'
	? state
	: {
	phase: 'animating',
	progress: clamp(increment(0), action.minimum, 1),
	}

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[tanem]

Fixed in 3a87f7d. The minimum section now describes the guard in the start reducer case rather than the opposite behaviour.

react-nprogress/README.md

Lines 134 to 137 in 3a87f7d

	#### `minimum`
	Lower bound for `progress`, between `0` and `1`. The first increment starts from `0.1` rather than from `0`, so the bar appears at `max(0.1, minimum)` and the option only shows through when it is set above `0.1`. Changing it while the bar is animating does not rewind the bar. Progress holds where it is, and the new bound applies from the next increment.

[tanem]

Also fixed the isAnimating timing sentence in 40c1cfe, which was missing its unit. It now reads "isFinished becomes true animationDuration milliseconds later", matching how the animationDuration section states the same delay.

react-nprogress/README.md

Lines 130 to 133 in 40c1cfe

	#### `isAnimating`
	Whether the bar is running. Going `true` starts it, going `false` completes it. Completion is what drives the final state: `progress` is set to `1`, and `isFinished` becomes `true` `animationDuration` milliseconds later.