Skip to content

Replace deprecated source-map-resolve with a maintained alias - #2900

Open
Alexandro Marques (alexandroit) wants to merge 1 commit into
microsoft:masterfrom
alexandroit:chore/use-stackline-source-map-resolve
Open

Replace deprecated source-map-resolve with a maintained alias#2900
Alexandro Marques (alexandroit) wants to merge 1 commit into
microsoft:masterfrom
alexandroit:chore/use-stackline-source-map-resolve

Conversation

@alexandroit

Copy link
Copy Markdown

sourceMapsCombinator currently imports source-map-resolve@0.5.3 and calls its synchronous resolveSync API while combining debugger source maps, including Windows drive-letter handling.

This changes only the existing dependency key and lockfile to the exact npm alias:

"source-map-resolve": "npm:@stackline/source-map-resolve@1.0.0"

Imports, the existing drive-letter workaround, and the repository's ambient declaration remain unchanged. The replacement preserves the seven-function CommonJS API, synchronous and callback behavior, and error metadata; it supports the repository's Node 20 CI runtime and corrects Windows cross-drive path retention.

Disclosure: I maintain @stackline/source-map-resolve. It is an MIT compatibility fork and is not affiliated with or endorsed by the original maintainer. This is a maintenance proposal, not a claim that a clean source-map-resolve@0.5.3 installation is currently vulnerable.

Validation on the current base commit 5403c435aeb41fa4c3542490f37adab71782e5d4:

  • npm ci
  • npx gulp
  • npm run build — 0 errors; the same 157 existing warnings
  • focused sourceMapsCombinator Mocha test — 1 passing
  • npm test -- --verbose — 358 passing, 1 pending
  • npm run test-localization -- --verbose — 2 passing when run after the required gulp/build sequence

The package separately characterizes shared ordinary behavior against 0.5.3, but does not reproduce that release's deprecated dependency topology or claim byte-for-byte 0.5.x equivalence. I retained the local type declaration to keep this migration focused; adopting the package's stricter first-party types can be evaluated separately.

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

@alexandroit

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant