Bump resolve-url-loader to v5 to drop forbidden postcss@7.0.39 (8.16.2) by jsbalrog · Pull Request #427 · fs-webdev/create-react-app

jsbalrog · 2026-08-07T17:21:17Z

Problem

Artifactory's security policy now returns 403 Forbidden for postcss-7.0.39.tgz. That breaks npm install on the build/publish step of every app consuming @fs/react-scripts — the failure surfaces in consumers, not here, which makes it easy to misdiagnose as an app-level problem.

postcss@7.0.39 reaches consumers only transitively:

@fs/react-scripts
  └─ resolve-url-loader@4.0.0   (declares postcss ^7.0.35)
       └─ postcss@7.0.39        ← forbidden tarball

7.0.39 is the last release on the postcss 7 line, and the relevant ReDoS advisory was only ever patched in postcss 8.4.31+ — there is no allowed 7.x to fall back to. npm update can't help either: the parent semver ranges (^7.0.35, ^4.0.0) cap it inside its current majors.

Fix

Bump resolve-url-loader ^4.0.0 → ^5.0.0 in packages/react-scripts/package.json. v5 depends on postcss 8, so postcss@7.0.39 leaves the tree entirely. Fixing it here retires the issue for every consumer at once, instead of each app carrying a local overrides workaround.

Included in this PR (self-contained release):

resolve-url-loader bump
version 8.16.1 → 8.16.2
CHANGELOG-FRONTIER.md entry
regenerated root package-lock.json

Compatibility

The webpack config (packages/react-scripts/config/webpack.config.js) passes only sourceMap and root to the loader — both still supported in v5. v5 dropped only the deprecated engine / keepQuery / absolute / attempts options, none of which are used here.
v5 drops Node < 12 support — a non-issue for current apps.

Verification

Check	Result
`postcss@7.0.39` in lockfile	✅ gone (0 occurrences)
`resolve-url-loader` resolved	✅ `5.0.0`
lockfile records `@fs/react-scripts`	✅ `8.16.2`

The full react-scripts suite runs in CI (Azure Pipelines) on this PR. As an additional real-world signal, the equivalent change was validated end-to-end in a consumer: ux-playground built successfully in production mode with resolve-url-loader@5 (applied via an npm overrides entry as an interim fix — fs-webdev/ux-playground#190), which exercises the same Sass/CSS url()-rewriting pipeline this loader drives.

After this ships

Consumers can bump to @fs/react-scripts@8.16.2 and remove their interim resolve-url-loader override (e.g. ux-playground's).

🤖 Generated with Claude Code

….16.2) Artifactory's security policy now returns 403 Forbidden for postcss-7.0.39.tgz, which breaks `npm install` on the build/publish step of every app consuming @fs/react-scripts. postcss@7.0.39 reached consumers only transitively via resolve-url-loader@4: @fs/react-scripts -> resolve-url-loader@4 -> postcss@7.0.39 7.0.39 is the last 7.x release and the relevant ReDoS advisory was only patched in postcss 8.4.31+, so there is no allowed 7.x fallback. resolve-url-loader v5 uses postcss 8, removing postcss 7 entirely. The webpack config passes only `sourceMap` and `root` to the loader, both still supported in v5 (v5 dropped only the deprecated engine/keepQuery/absolute/attempts options). v5 also drops Node < 12 support, a non-issue for current apps. Verified: postcss@7.0.39 gone from the lockfile, resolve-url-loader@5.0.0 resolved. The equivalent change was validated end-to-end in a consumer (ux-playground built successfully in production mode with resolve-url-loader@5 via an npm override), exercising the same Sass/CSS pipeline this loader drives. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

redbugz · 2026-08-07T17:57:33Z

Travis npmrc needs to be updated to not scope to @fs but to use artifactory for all dependencies

Copilot

Pull request overview

This PR updates @fs/react-scripts to remove the forbidden transitive dependency on postcss@7.0.39 (blocked by Artifactory), by bumping resolve-url-loader to v5 (which uses PostCSS 8) and releasing @fs/react-scripts@8.16.2.

Changes:

Bump resolve-url-loader from ^4.0.0 to ^5.0.0 and update the root lockfile accordingly (removing postcss@7.0.39 from the dependency tree).
Bump @fs/react-scripts version 8.16.1 → 8.16.2.
Add a CHANGELOG-FRONTIER.md entry and adjust Travis registry configuration.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
packages/react-scripts/package.json	Version bump and dependency bump to `resolve-url-loader@^5`.
package-lock.json	Regenerated lockfile reflecting `resolve-url-loader@5` and PostCSS 8.
CHANGELOG-FRONTIER.md	Documents the dependency/security-related release rationale for `8.16.2`.
.travis.yml	Updates npm registry configuration used during CI install/publish steps.

Suppressed comments (1)

.travis.yml:26

Same registry/auth endpoint mismatch here: the lockfile resolved URLs and publishConfig.registry use .../artifactory/api/npm/..., but this .npmrc writes credentials for .../familysearch/api/npm/.... Using the /artifactory/api/npm/ endpoint consistently avoids auth-token scoping issues during the additional installs in freshCraTemplateUpdate.sh.

  - echo "//familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/:_authToken=${NPM_PUBLISH_TOKEN}" >> ${HOME}/tmp/fresh-cra-template/.npmrc
  - echo "registry=https://familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/" >> ${HOME}/tmp/fresh-cra-template/.npmrc

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

  - echo "//familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/:_authToken=${NPM_PUBLISH_TOKEN}" >> ~/.npmrc
-  - echo "@fs:registry=https://familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/" >> ~/.npmrc
+  - echo "registry=https://familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/" >> ~/.npmrc
    # because this is a weird monorepo and we cd into and out of directories, this is what worked for travis to publish
  - echo "//familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/:_authToken=${NPM_PUBLISH_TOKEN}" >> packages/react-scripts/.npmrc
-  - echo "@fs:registry=https://familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/" >> packages/react-scripts/.npmrc
+  - echo "registry=https://familysearch.jfrog.io/familysearch/api/npm/fs-npm-prod-virtual/" >> packages/react-scripts/.npmrc


Artifactory's curation service returns 403 for any package version with a CVSS >= 9 CVE that has a fix available. Eight transitive versions in the tree were blocked, failing `npm install` in CI: axios@0.25.0 (docusaurus/website <- wait-on) undici@6.19.8 (docusaurus/website <- cheerio) handlebars@4.7.8 (root devDeps <- lerna) lodash.template@4.5.0 (root devDeps <- lerna) form-data@2.3.3 (root devDeps <- request <- node-gyp) tough-cookie@2.5.0 (root devDeps <- request <- node-gyp) parse-url@6.0.5 (root devDeps <- git-up <- lerna) plist@2.1.0 (root devDeps <- svg-term-cli) None are in the published @fs/react-scripts runtime tree, so no consumer was affected and no version bump is required. Fixes, in order of preference: - Drop the `docusaurus/website` workspace. Nothing builds it (no script or CI step references it) and it is pinned to @docusaurus/core 2.0.0-alpha.64 inherited from upstream. Removing it eliminates axios@0.25.0 and undici@6.19.8 outright, with no override needed. - Refresh handlebars 4.7.8 -> 4.7.9 and lodash.template 4.5.0 -> 4.18.1; both already satisfied their parents' ranges. - Add root `overrides` for the four whose parent ranges cap them below the patched version (request's ~2.3.2/~2.5.0, git-up's ^6.0.0, svg-term-cli/term-schemes' ^2.1.0). All are dev-only tooling, and the root package is private so these cannot reach consumers. Verified with a cold-cache `npm ci` against a scratch copy of the tree: 2919 packages installed, zero curation blocks. A warm npm cache masks these failures locally, since curation is enforced on tarball fetch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

create-react-app exits 0 even when installing the template's dependencies fails: init.js logs "`npm install ...` failed" and returns. That is deliberate upstream behavior, not a bug -- exiting non-zero makes create-react-app's error handler delete the generated app's package.json and node_modules, which would destroy a scaffold that only needs `npm install` re-run. So this asserts on the result instead of changing init.js, and keeps the fork from diverging further on an upstream file. Without it the real failure surfaced two steps later as `sh: 1: react-scripts: not found` (exit 127), which reads like a react-scripts packaging problem. The actual cause in the build that prompted this was postcss@7.0.39 being blocked by jfrog curation, reached via the template's Storybook 6 devDependencies and via the upstream react-scripts that @storybook/preset-create-react-app pulls in as a peer -- neither of which involves @fs/react-scripts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fix Travis build

f458a53

redbugz requested review from a team and a lite review from Copilot August 7, 2026 18:35

redbugz self-assigned this Aug 7, 2026

Copilot started reviewing on behalf of redbugz August 7, 2026 18:36 View session

Copilot AI reviewed Aug 7, 2026

View reviewed changes

redbugz and others added 3 commits August 7, 2026 13:19

fix artifactory path

3ab9d67

Navigation Menu

Uh oh!

Bump resolve-url-loader to v5 to drop forbidden postcss@7.0.39 (8.16.2) - #427

Bump resolve-url-loader to v5 to drop forbidden postcss@7.0.39 (8.16.2)#427
jsbalrog wants to merge 5 commits into
frontierMasterfrom
jsbalrog/bump-resolve-url-loader-v5

jsbalrog commented Aug 7, 2026

Uh oh!

redbugz commented Aug 7, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

jsbalrog commented Aug 7, 2026

Problem

Fix

Compatibility

Verification

After this ships

Uh oh!

redbugz commented Aug 7, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants