Maintainer decision: retain, alias, or remove resolve-url-loader from the Sass pipeline?

[alexandroit]

@gravity-ui/app-builder@0.52.2 currently ships resolve-url-loader@^5.0.0 as a runtime dependency and resolves it by the historical package name in createSassStylesRule:

• declaration:

  app-builder/package.json

  Line 142 in ed3d9d4

  "resolve-url-loader": "^5.0.0",

• loader chain:

  app-builder/src/common/webpack/config.ts

  Lines 840 to 863 in ed3d9d4

  	function createSassStylesRule(options: HelperOptions): webpack.RuleSetRule {
  	const loaders = getCssLoaders(options, [
  	{
  	loader: require.resolve('resolve-url-loader'),
  	options: {
  	sourceMap: !options.config.disableSourceMapGeneration,
  	},
  	},
  	{
  	loader: require.resolve('sass-loader'),
  	options: {
  	sourceMap: true, // must be always true for work with resolve-url-loader
  	sassOptions: {
  	loadPaths: [paths.appClient],
  	},
  	},
  	},
  	]);
  	return {
  	test: /\.scss$/,
  	sideEffects: options.isEnvProduction ? true : undefined,
  	use: loaders,
  	};

The chain deliberately keeps sass-loader source maps enabled for URL rebasing, and earlier fixes such as #56 and #163 show that its loader ordering/options are behaviorally important.

Before preparing a patch, which maintenance direction would you prefer?

1. Keep the current source/config unchanged and use the exact historical-key npm alias:

   "resolve-url-loader": "npm:@stackline/resolve-url-loader@1.0.0"

2. Intentionally retain resolve-url-loader@5.0.0.

3. Plan to remove or replace URL rebasing in the Sass pipeline instead.

The upstream v5 package is not deprecated, and I am not reporting a vulnerability: a fresh current install has no production audit finding. The concern is maintenance continuity—v5 was published in January 2022 and its repository has had no push since December 2022—while app-builder is actively validating current Webpack/Sass releases and passes this dependency on to its own consumers.

Option 1 preserves require.resolve('resolve-url-loader') and the existing loader configuration. If that direction is welcome, I can prepare a focused package.json/pnpm-lock.yaml patch and verify it with Node 24 / pnpm 10.17.1 using:

• pnpm install --frozen-lockfile
• pnpm run lint
• pnpm run typecheck
• pnpm run test
• pnpm run build
• the repository CI example builds

If you prefer option 2 or 3, I will leave the dependency unchanged.

Disclosure: I (alexandroit) maintain the independent @stackline/resolve-url-loader compatibility continuation proposed in option 1. I am not affiliated with Gravity UI or the original resolve-url-loader maintainers. This is a dependency-maintenance decision request, not a security report or security-fix claim.

References:

• https://www.npmjs.com/package/@stackline/resolve-url-loader
• https://github.com/alexandroit/stackline-resolve-url-loader
• https://github.com/alexandroit/stackline-resolve-url-loader/releases/tag/stackline-v1.0.0