Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix: resolve Windows ESM loader error (issue #3887)#3950

Open
moshkinura wants to merge 2 commits intoprettier:mainfrom
moshkinura:fix/issue-3887-windows-esm-loader-error
Open

fix: resolve Windows ESM loader error (issue #3887)#3950
moshkinura wants to merge 2 commits intoprettier:mainfrom
moshkinura:fix/issue-3887-windows-esm-loader-error

Conversation

@moshkinura
Copy link

Description

This PR fixes the extension activation error on Windows that occurs after the ESM conversion in commit 74b56c7. The error message is:
Activating extension 'prettier.prettier-vscode' failed: Only URLs with a scheme in: file, data, node, and electron are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'd:'.

Root Cause:
VS Code extension host does not support native ES Module ("type": "module") extensions. The ESM conversion attempted to use native ESM format, which is incompatible with the VS Code extension host on all platforms, but the error manifests specifically on Windows due to how Node.js ESM loader handles absolute paths.

Solution:

  • Removed "type": "module" from package.json to restore CommonJS compatibility
  • Reverted esbuild node configuration from ESM to CommonJS format (format: "cjs", platform: "node")
  • Removed unnecessary external modules from esbuild config (fs, path, url, etc.) that should be bundled
  • Fixed createRequire() in resolvers.ts to use pathToFileURL() for proper Windows path handling

This restores the working configuration from v12.0.4, which uses CommonJS format compatible with VS Code extension host on all platforms (Windows, Linux, macOS).

Related Issue

Fixes #3887

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Refactoring (no functional changes)
  • CI/Build changes

Checklist

  • I have read the CONTRIBUTING guidelines
  • My code follows the code style of this project (npm run lint passes)
  • I have run npm run prettier to format my code
  • I have added/updated tests that prove my fix or feature works
  • All new and existing tests pass (npm test)
  • I have updated the CHANGELOG.md with a summary of my changes

Additional Notes

  • The extension builds successfully with these changes
  • The fix is compatible with all platforms (Windows, Linux, macOS)
  • This reverts the problematic ESM conversion while maintaining all functionality
  • No functional changes to the extension behavior, only build configuration fixes

Fix activation error on Windows: 'Only URLs with a scheme in: file, data, node, and electron are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol d:.'

Changes:
- Remove 'type: module' from package.json (VS Code extension host doesn't support native ESM extensions)
- Revert esbuild node config to CommonJS format (cjs) with platform: 'node'
- Remove unnecessary external modules from esbuild config
- Fix createRequire() in resolvers.ts to use pathToFileURL() for Windows compatibility

This reverts the ESM conversion from commit 74b56c7 and restores the working CJS configuration from v12.0.4, which is compatible with VS Code extension host on all platforms (Windows, Linux, macOS).

The error was specific to Windows because Node.js ESM loader requires file:// URLs for absolute paths on Windows, but VS Code extension host doesn't support native ESM extensions yet.
@aarock1234
Copy link

Would be nice to have this merged

@tomchen
Copy link

tomchen commented Jan 26, 2026

VS Code 1.100 and Antigravity (based on VS Code v1.104.0), both released in December or earlier, support ESM extensions. Cursor, however, despite claiming to be based on VS Code v1.105.1 since December, did not support ESM. After Cursor 2.4.21 introduced a fix for Linux a week ago, this has now become a Cursor-on-Windows-only problem. I can confirm that on Windows, the latest VS Code and Antigravity do not have this issue with the latest Prettier extension.

Therefore, it is logically Cursor's responsibility to fix this, not the extensions'. Instead of spending so much effort repeatedly breaking the UI layout in every release, Cursor should focus on something more important, like the ESM issue.

The core maintainer of the Prettier extension has already spoken against rolling back to CJS when this was a Cursor-only issue. Now that it is a Cursor-on-Windows-only problem, rolling back to CJS makes even less sense.

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.

Extension not working in Cursor

3 participants