Additional config changes

[Ryang-21]

• Forces typescript src files to use .js on relative imports. As we migrate I think it'd save time if we imported with ESM compatibility.

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		License policy violation: npm tslib under 0BSD Location: Package overview From: pnpm-lock.yaml → npm/tslib@2.8.1 ℹ Read more on: This package | This alert | What is a license policy violation? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/tslib@2.8.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[github-actions]

Size Change: 0 B

Total Size: 3.51 MB

ℹ️ View Unchanged

Filename	Size
dist/stellar-base.js	2.59 MB
dist/stellar-base.min.js	920 kB

_{compressed-size-action}

[Copilot]

Pull request overview

This pull request prepares the codebase for ESM (ECMAScript Module) migration by enforcing that TypeScript source files use .js extensions on relative imports. The changes ensure compatibility with ESM while the project is still using CommonJS and transitioning to TypeScript.

Changes:

• Adds ESLint rule to enforce .js extensions on all TypeScript relative imports
• Configures build tools (webpack) and test infrastructure to resolve .js imports to .ts files
• Adds VS Code workspace settings for consistent tooling configuration

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
test/test-helper.js	Patches Node.js module resolution to allow .js imports to resolve to .ts files during testing
pnpm-lock.yaml	Adds eslint-plugin-import-x@4.16.1 and its transitive dependencies (including unrs-resolver with platform-specific native bindings)
package.json	Adds eslint-plugin-import-x as a devDependency
config/webpack.config.browser.js	Configures webpack extensionAlias to resolve .js imports to .ts or .js files in order of preference
config/eslint.config.cjs	Adds import-x/extensions rule to enforce .js extensions on all TypeScript relative imports (ignoring package imports)
.vscode/settings.json	Configures VS Code to use the project's ESLint and Prettier configuration files

Files not reviewed (1)

• pnpm-lock.yaml: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The module resolution patch only handles the case when a .js file doesn't exist and tries to resolve to .ts. However, this approach will catch and swallow ANY error that occurs during the first resolution attempt, not just "file not found" errors. This could hide legitimate errors like circular dependencies, syntax errors in module resolution, or permission issues. Consider checking the error code to ensure it's specifically a MODULE_NOT_FOUND error before attempting the .ts fallback.

[Copilot]

The module resolution patch will also affect all .js imports throughout the test suite, not just relative imports. This means if any third-party package is imported with a .js extension that doesn't exist, it will try to resolve to a .ts file, which could lead to unexpected behavior or confusing error messages. Consider adding a check to only apply the patch to relative imports (those starting with . or ..) by checking if request starts with . before attempting the .ts resolution.

[Copilot]

The extensionAlias configuration maps .js to [".ts", ".js"], which means webpack will try .ts first, then .js. However, this could cause confusion during development if both a .ts and .js file with the same name exist in the same directory, as webpack will always prefer the .ts file. While this is unlikely in a well-organized codebase, consider documenting this behavior or adding validation to prevent such scenarios.

[Copilot]

When the module resolution patch attempts to resolve the .ts file (line 9-14), if that also fails, the error thrown will be about the .ts file not being found, not the original .js file. This could make debugging more confusing. Consider catching the second error and re-throwing the original error with additional context about the attempted .ts resolution.

Suggested change

	return originalResolveFilename.call(
	this,
	request.replace(/\.js$/, ".ts"),
	parent,
	...args
	);
	const originalError = err;
	const tsRequest = request.replace(/\.js$/, ".ts");
	try {
	return originalResolveFilename.call(
	this,
	tsRequest,
	parent,
	...args
	);
	} catch (tsErr) {
	originalError.message +=
	` (and failed to resolve corresponding TypeScript file "${tsRequest}" as well: ${tsErr.message})`;
	throw originalError;
	}

[quietbits]

Is this something we'll need to keep after the migration is done?

[quietbits]

How will this work with existing .vscode settings locally?

[Ryang-21]

Hmm Im not sure about I initially wanted to commit this because of where the configs are stored the editor fails to pick them up by default. In hindsight though I think this folder is generally git ignored.

[Ryang-21]

This is module resolution changes in the test-helper.js file should be temporary as vitest does not require this. The webpack changes will need to stay if we stick with webpack.