Bump sass-loader from 13.3.3 to 16.0.8#1481
Conversation
Bumps [sass-loader](https://github.com/webpack/sass-loader) from 13.3.3 to 16.0.8. - [Release notes](https://github.com/webpack/sass-loader/releases) - [Changelog](https://github.com/webpack/sass-loader/blob/main/CHANGELOG.md) - [Commits](webpack/sass-loader@v13.3.3...v16.0.8) --- updated-dependencies: - dependency-name: sass-loader dependency-version: 16.0.8 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
There was a problem hiding this comment.
Stale comment
No blocking findings.
Security
- I did not find any current public advisories or known CVEs affecting
sass-loader@16.0.8.- The package still resolves to the same direct runtime dependency (
neo-async), so this PR does not expand the dependency surface.- Dependabot notes an upstream
preparescript change, but that is package-maintainer workflow rather than an install-time script this repo executes from the npm registry package. Localyarn install --immutablecompleted cleanly with no dependency-script issues.Safety of merging
- The main breaking changes between
13.3.3and16.xare:
14.0.0raises the minimum Node version to>=18.12.0and removesfiberssupport.15.0.0preferssass-embeddedoversasswhen both are installed.16.0.0defaults to the modern Sass JS API.- This repository already appears aligned with those changes:
webpack.config.jsexplicitly setssass-loadertoapi: "modern".- The only configured
sassOptionsuseloadPaths, which is valid with the modern API.- I did not find legacy-only loader options in this repo (
data,file, legacy importer/functions config, etc.).- I did not find
~Sass imports that would raise additional migration concerns.- The repo pins Node
20.20.0in.tool-versions, and CI uses Node 20 in.github/workflows/ci-cd.yml, so the Node floor increase is satisfied in the supported environments.- The repo depends on
sass, notsass-embedded, so the15.0.0default-preference change should not alter behavior here.- Net: for this codebase, the semver-major risk is real in general, but the repository is already configured in the direction that
sass-loader@16expects.Tests
Local:
yarn install --immutable✅yarn lint✅yarn stylelint✅CI=true yarn run test --coverage --maxWorkers=4 --workerThreads=true --reporters=default --reporters=jest-junit --reporters=jest-github-actions-reporter✅ (92suites,835tests passed)yarn build✅
- Build completed without Sass errors; only the existing webpack asset-size/performance warnings were reported.
Hosted PR checks at review time:
lint✅test✅deploy-branch / build-deploy✅test-cypressis still in progressI could not complete a local Cypress run in this VM because the Cypress desktop binary was not present and repeated
cypress installattempts did not yield a usable local binary here.Recommendation
Merge.
Residual risk looks low for this repository. The only thing still worth watching is the hosted
test-cypressjob before merging, since that is the remaining browser-level validation not yet complete in this environment.Sent by Cursor Automation: Editor-UI - Tests Dependabot PRs
There was a problem hiding this comment.
No blocking findings.
Security
- I couldn't find any published CVEs/advisories affecting
sass-loader@16.0.8; public package-security sources currently show no known direct vulnerabilities for this package. - The runtime supply-chain footprint is effectively unchanged: the lockfile still resolves the same direct dependency (
neo-async), and the newly listed@rspack/corepeer is optional and unused in this repo. sass-loaderdoes not addpreinstall/install/postinstallhooks. Upstream'spreparescript changed, but that script is not executed for normal npm registry installs, so it does not introduce new install-time risk here.
Safety Of Merging
- The meaningful upstream breaking changes across
13.3.3 -> 16.0.8are: minimum Node version>=18.12.0(v14), preferringsass-embeddedwhen present (v15), and using the modern Sass JS API by default (v16). - This repository looks compatible with those changes: CI is configured for Node 20 in
.github/workflows/ci-cd.yml, the webpack rule already opts intoapi: "modern"inwebpack.config.js, and it only uses modern-compatible options (sassOptions.loadPathsandsourceMap). - I did not find any repo usage of
fibers,node-sass,sass-embedded, or legacy-only loader options that would make this bump risky.
Test Results
- Local on the PR head:
yarn install --immutable✅yarn lint✅CI=true yarn run test --coverage --maxWorkers=4 --workerThreads=true --reporters=default --reporters=jest-junit --reporters=jest-github-actions-reporter✅ (92suites /835tests passed)yarn build✅ (webpack compiled successfully)
- I could not complete local Cypress because this VM could not download the Cypress binary from
download.cypress.io(SSL_ERROR_SYSCALL/ binary not installed). - The PR's GitHub Actions
test-cypresscheck has completed successfully, so the hosted full suite is green.
Recommendation
Recommend merge. The main major-version risks are already accounted for by this repo's current setup, and both local CI-style checks and hosted CI passed.
Sent by Cursor Automation: Editor-UI - Tests Dependabot PRs


Bumps sass-loader from 13.3.3 to 16.0.8.
Release notes
Sourced from sass-loader's releases.
... (truncated)
Changelog
Sourced from sass-loader's changelog.
... (truncated)
Commits
4f00ed5chore(release): 16.0.890e349dfix: normalize separators in getPossibleRequests for Windows (#1308) (#1309)cda2078chore(deps-dev): bump follow-redirects from 1.15.9 to 1.16.0 (#1306)128abc0chore(deps): bump lodash from 4.17.23 to 4.18.1 (#1305)e3df97dchore(deps-dev): bump node-forge from 1.3.3 to 1.4.0 (#1304)ff8005bchore(deps): bump serialize-javascript and terser-webpack-plugin (#1299)7dd2827chore(deps-dev): bump flatted from 3.3.2 to 3.4.2 (#1301)9e6a5e5chore(deps): bump picomatch (#1300)a488645chore(deps): bump immutable from 5.0.3 to 5.1.5 (#1298)fe6fe07chore(deps-dev): bump js-yaml from 3.14.1 to 3.14.2 (#1297)Install script changes
This version modifies
preparescript that runs during installation. Review the package contents before updating.Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)