v7.0.0

.github/workflows/ci.yml

@@ -2,9 +2,9 @@ name: CI
 
 on:
   push:
-    branches: [master]
+    branches: [master, 'v*']
   pull_request:
-    branches: [master]
+    branches: [master, 'v*']
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}

.gitignore

@@ -1,10 +1,7 @@
 *.log
 .DS_Store
 .vscode
-compiled
 coverage
 dist
 examples/*/package-lock.json
-examples/umd-dev/.cache
-examples/umd-prod/.cache
 node_modules

.prettierignore

@@ -1,5 +1,5 @@
 README.md
-compiled
 coverage
 dist
+next-env.d.ts
 package.json

.github/copilot-instructions.md → AGENTS.md

@@ -1,20 +1,24 @@
-# Copilot Instructions for react-nprogress
+# Agent Instructions for react-nprogress
 
 Keep these instructions concise. Only add information here that meaningfully
 changes agent behaviour and cannot be inferred from the codebase or tooling.
 
 ## Project
 
-TypeScript React library providing a slim progress bar primitive via three
-patterns: `useNProgress` hook, `NProgress` render-props component, and
-`withNProgress` HOC. Exports logic only, not rendering. All exports go through
-`src/index.tsx`. Types live in `src/types.ts`.
+TypeScript React library providing a slim progress bar primitive via two
+patterns: `useNProgress` hook and `NProgress` render-props component. Exports
+logic only, not rendering. All exports go through `src/index.tsx`. Types live
+in `src/types.ts`. There are no runtime dependencies: React and React DOM are
+peers.
 
 ## Key Commands
 
 ```bash
-npm test          # full suite: type-check, lint, build, all format tests
-npm run build     # clean + compile + bundle
+npm test          # full suite: format and type checks, lint, build, size
+                  # gate, then every test:* script
+npm run build     # clean, then bundle with tsdown; the postbuild hook runs
+                  # publint and arethetypeswrong over the packed tarball
+npm run test:src  # source-only tests, the loop to use while developing
 npm run format    # fix lint and formatting
 ```
 
@@ -57,9 +61,18 @@ Managed by Renovate (`config:js-lib` preset):
 
 ## Testing
 
-- **100% code coverage** required across all build formats
+- **100% code coverage** of `src` is required. Coverage is collected by
+  `npm run test:src` only. No `coverageThreshold` is configured, so a drop
+  will not fail the run: read the report.
+- `npm run test:cjs` and `npm run test:es` re-run the hook and component
+  specs against `dist/react-nprogress.cjs` and `dist/react-nprogress.mjs`,
+  and `npm run test:bundles` asserts what the build emits, so all three need
+  a build first. `npm test` builds before running them.
+- `test/bundles.spec.ts` is excluded from `config.src.js` so that `test:src`
+  and the React matrix stay runnable without a build. A new spec that reads
+  `dist` belongs in `config.bundles.js`, not alongside the source specs.
 - Always run `npm test` after changes; use `npm run test:src` for quick
-  source-only feedback during development
+  source-only feedback during development.
 - Use `npm run test:react` for the full React version matrix independently.
   It also runs as part of `npm test` (via the `test:*` glob).
 
@@ -68,7 +81,7 @@ Managed by Renovate (`config:js-lib` preset):
 We test boundary versions only: first and last minor of each supported
 major. See `test/react/` for current versions.
 
-Current boundaries: 16.14, 17.0, 18.0, 18.3, 19.0.
+Current boundaries: 16.14, 17.0, 18.0, 18.3, 19.0, 19.2.
 
 React 16.14 is the practical lower bound. Hooks require 16.8 and
 `@testing-library/react-hooks` requires 16.9.
@@ -80,13 +93,21 @@ When adding a new boundary:
    16.x for React 18+). React 16–17 also need
    `@testing-library/react-hooks` (8.x) and `react-test-renderer`.
 2. Replace the previous "latest minor" for that major.
-3. Verify with a single-version run before the full matrix:
+3. Verify with a single-version run before the full matrix. Install inside
+   the version directory, but run jest from the repo root: the config sets
+   `rootDir` to the current working directory.
    ```bash
-   cd test/react/<version> && npm i --no-package-lock --quiet --no-progress
+   (cd test/react/<version> && npm i --no-package-lock --quiet --no-progress)
    REACT_VERSION=<version> npx jest --config ./scripts/jest/config.src.js --coverage false
    ```
 4. Update the boundary list above.
 
+## Packaging
+
+`size-limit` gates the gzipped size of both bundles, configured in
+`package.json`. Treat a limit bump as a decision, not a fix: only raise it
+when the added size is intended.
+
 ## Examples
 
 Examples live in `examples/` and are designed to open on CodeSandbox. Their
@@ -112,6 +133,18 @@ needed but test on CodeSandbox before merging.
 Do not bump vite, @vitejs/plugin-react, next, or typescript in examples
 beyond the versions in the reference templates.
 
+Before a release that changes packaging, smoke-test the examples against the
+tarball rather than the registry: `npm run build && npm pack` at the repo
+root, point each example's `@tanem/react-nprogress` dependency at the tarball,
+clean-install so it wins over any stale `node_modules`, then run the example
+and drive its progress bar in a browser. The Next examples also need
+`next build && next start`, since they resolve the CJS entry on the server.
+Restore the `"latest"` pin afterwards: CodeSandbox resolves the registry.
+
+`next-env.d.ts` in the Next examples is generated, and `next dev` and
+`next build` write different contents into it, so it is gitignored and listed
+in `.prettierignore` rather than tracked.
+
 ## Writing Style
 
 - Avoid marketing or promotional language. State facts plainly.
@@ -126,6 +159,20 @@ beyond the versions in the reference templates.
 Strict semver: no breaking changes without a major version bump, including
 technical refactors.
 
+Every breaking change needs a MIGRATION.md entry under the target major's
+heading, describing the change and the action required.
+
+## Releases
+
+`.github/workflows/release.yml` runs on a Monday cron against master with no
+content gate: whatever is on master ships in the next release.
+
+`tanem-scripts release` derives the bump from PR labels. Every PR merged
+since the last tag must carry exactly one label, ignoring `safe to test`. It
+throws on unlabelled and on multi-labelled PRs. `breaking` selects a major,
+`enhancement` a minor, anything else a patch. Renovate labels its own PRs
+`internal`.
+
 ## Documentation
 
 - After each code change, update all related docs and markdown files

CLAUDE.md

@@ -0,0 +1 @@
+@AGENTS.md

MIGRATION.md

@@ -1,5 +1,73 @@
 # Migrating
 
+## v7.0.0
+
+### `withNProgress` removed
+
+React's docs treat higher-order components as a legacy pattern, and the HOC
+was the package's only reason to depend on `hoist-non-react-statics`.
+
+**Action required:** wrap the component yourself:
+
+```jsx
+const Enhanced = (props) => <Inner {...props} {...useNProgress(props)} />
+```
+
+Statics hoisting goes with it. If the wrapped component has statics that
+consumers read off the wrapper, copy them across yourself.
+
+### UMD builds removed
+
+`dist/react-nprogress.umd.development.js` and
+`dist/react-nprogress.umd.production.js` are no longer published. React 19
+does not ship a UMD build of its own, so the script-tag path already only
+worked with React 18 and earlier.
+
+**Action required:** for script-tag usage, pin
+`@tanem/react-nprogress@^6`. Otherwise install the package and consume it
+through a bundler.
+
+### `exports` map added
+
+`@tanem/react-nprogress` and `@tanem/react-nprogress/package.json` are the
+only entry points. Paths into `dist` are no longer reachable, even though the
+top-level `main`, `module` and `types` fields are still set for webpack 4 and
+TypeScript `node10` resolution. Node ESM consumers now get the ES module
+build rather than falling back to CommonJS, which Node did previously because
+it ignores `module`.
+
+**Action required:** import from the package name. `src` is now published
+alongside `dist` so the declaration maps resolve.
+
+### Build output filenames changed
+
+The build moved from TypeScript plus Rollup and Babel to
+[tsdown](https://tsdown.dev). The CommonJS build is
+`dist/react-nprogress.cjs` (was `dist/index.js` switching between
+`dist/react-nprogress.cjs.development.js` and
+`dist/react-nprogress.cjs.production.js`) and the ES module build is
+`dist/react-nprogress.mjs` (was `dist/react-nprogress.esm.js`). Type
+declarations are `dist/react-nprogress.d.cts` and
+`dist/react-nprogress.d.mts`, replacing `dist/index.d.ts` plus one file per
+source module. Output still targets ES2019.
+
+**Action required:** none if you import `@tanem/react-nprogress`.
+
+### Separate development and production CommonJS builds removed
+
+`process.env.NODE_ENV` is no longer read at require time. The two builds
+differed only by minification, which bundlers apply themselves.
+
+**Action required:** none. Tooling that shimmed `process.env` solely to
+require this package can drop the shim.
+
+### `@babel/runtime` no longer a dependency
+
+The package now has no runtime dependencies, only peers.
+
+**Action required:** none, unless you depended on `@babel/runtime` being
+installed transitively, in which case depend on it directly.
+
 ## v6.0.0
 
 Trickle pacing was adjusted to more closely match the original
@@ -18,12 +86,12 @@ behaviour.
 
 ### Intermediate progress updates no longer wait for `animationDuration`
 
-Non-completion `set()` calls previously waited `animationDuration`
-(200 ms) before advancing the internal queue. This wait has been
+Intermediate progress updates previously waited `animationDuration`
+(200 ms) before the next one could be scheduled. This wait has been
 removed for intermediate updates so that only `incrementDuration`
-controls trickle pacing. The completion path (`set(1)`) still waits
-`animationDuration` before marking the bar as finished, giving
-consumers time to animate the bar to 100% before it disappears.
+controls trickle pacing. Completion still waits `animationDuration`
+before marking the bar as finished, giving consumers time to animate
+the bar to 100% before it disappears.
 
 **Action required:** none in most cases. If your rendering code relied
 on intermediate progress updates being spaced at least