fix(config): ERR_UNSUPPORTED_ESM_URL_SCHEME when loading JS config file on Windows

[alexvy86]

Syncpack version

14.0.2

Operating system(s)

Windows

Steps to reproduce

1. Create a repo with a syncpack.config.cjs config file.
2. Run npx syncpack lint

package.json

{
	"name": "syncpack-windows-repro",
	"version": "1.0.0",
	"private": true,
	"scripts": {
		"syncpack": "syncpack lint"
	}
}

syncpack.config.cjs

module.exports = {
	semverGroups: [
		{
			label: "Dependencies should use caret dependency ranges",
			dependencies: ["**"],
			dependencyTypes: ["dev", "peer", "prod"],
			packages: ["**"],
			range: "^",
		},
	],
};

Expected behavior

syncpack reads the config and runs normally.

Actual behavior

Node.js throws when trying to import() a file, I imagine the .cjs config file

  Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be  
  valid file:// URLs. Received protocol 'c:'
      at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:241:11)
      at defaultLoad (node:internal/modules/esm/load:132:3)
      at ModuleLoader.load (node:internal/modules/esm/loader:724:12)
      at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:543:56)
      at #createModuleJob (node:internal/modules/esm/loader:567:36)
      at #getJobFromResolveResult (node:internal/modules/esm/loader:297:34)
      at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:265:41)
      at async ModuleLoader.import (node:internal/modules/esm/loader:605:23)

Code of Conduct

• I agree to follow the Code of Conduct

[alexvy86]

Hey @JamieMason , Fluid Framework again here 😄 . We just realized this happens on Windows with Syncpack 14. Some research from Claude, in case it helps:

By inspecting the strings embedded in syncpack-windows-x64.exe, the binary spawns a child Node.js process using roughly:

node --experimental-strip-types --eval "import('C:\path\to\syncpack.config.cjs').then(...)"

On Linux/macOS, the path passed to import() is a POSIX absolute path (/home/.../syncpack.config.cjs), which Node.js's ESM loader accepts directly. On Windows, the path is a Win32 absolute path (C:...\syncpack.config.cjs). Node.js's ESM loader treats C: as a URL scheme (analogous to http: or file:), and since it's not a recognized scheme, it throws ERR_UNSUPPORTED_ESM_URL_SCHEME.

The fix is to convert the path to a proper file:// URL before passing it to import(), using Node.js's built-in pathToFileURL:

 import { pathToFileURL } from 'node:url';
 // instead of: import('C:\\path\\to\\config.cjs')
 import(pathToFileURL('C:\\path\\to\\config.cjs').href)
 // resolves to: import('file:///C:/path/to/config.cjs')  ✓

This is in src/rcfile/javascript.rs (based on binary symbol names).

[alexvy86]

I also confirmed that using a json config instead of cjs doesn't run into the problem.

[JamieMason]

Thanks @alexvy86, this will be the block:

syncpack/src/rcfile/javascript.rs

Lines 15 to 70 in 31f580a

	let nodejs_script = format!(
	r#"
	import('{escaped_file_path_for_nodejs}')
	.then(findConfig)
	.then((value) => {{
	if (isNonEmptyObject(value)) {{
	console.log(JSON.stringify({{
	_tag: 'Ok',
	value: JSON.stringify(value),
	source: 'import',
	}}));
	}} else {{
	tryRequire('Config expected at default export');
	}}
	}})
	.catch((err) => {{
	tryRequire(err.stack || err.message || 'Unknown error in import()');
	}});
	function tryRequire(importError) {{
	Promise.resolve(null)
	.then(() => require('{escaped_file_path_for_nodejs}'))
	.then(findConfig)
	.then((value) => {{
	if (isNonEmptyObject(value)) {{
	console.log(JSON.stringify({{
	_tag: 'Ok',
	value: JSON.stringify(value),
	source: 'require',
	}}));
	}} else {{
	console.log(JSON.stringify({{
	_tag: 'Err',
	importError,
	requireError: 'Config expected at module.exports',
	}}));
	}}
	}})
	.catch((err) => {{
	console.log(JSON.stringify({{
	_tag: 'Err',
	importError,
	requireError: err.stack || err.message || 'Unknown require error'
	}}));
	}});
	}};
	function isNonEmptyObject(value) {{
	return value && typeof value === 'object' && value.constructor === Object && Object.keys(value).length > 0;
	}}
	function findConfig(mod) {{
	return mod.default && mod.default.default ? mod.default.default : mod.default;
	}}
	"#
	);

I can take a look at the weekend or if you want to create a PR I can review that no problem too.

JSON as you mentioned avoids this (and is also much faster as a result) but you trade off the convenience of code comments and imports etc.