Updated configuration with vscode in mind#67
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates repository/package configuration to better support a CommonJS-oriented Node/Jest workflow (and VS Code local setup), as a preliminary step toward removing browser code.
Changes:
- Remove
"type": "module"from the rootpackage.jsonand update repository/issue tracker/homepage URLs. - Convert
jest.config.jsandbabel.config.jsfrom ESMexport defaultto CommonJSmodule.exports, and force Babel to emit CommonJS modules for Jest. - Ignore local
.vscode/and.status/directories in.gitignore.
Reviewed changes
Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| package.json | Removes package-level ESM default and updates repo metadata URLs. |
| jest.config.js | Switches Jest config export style to CommonJS for non-ESM package mode. |
| babel.config.js | Switches Babel config to CommonJS and forces module transform to CommonJS. |
| .gitignore | Adds ignores for local VS Code and status directories. |
Comments suppressed due to low confidence (1)
package.json:9
- Removing the root
"type": "module"makes.jsfiles in the package default to CommonJS. With the currentexportsmap, theimportcondition points at./dist/esm/index.js(ESM output from esbuild), which Node will now interpret as CommonJS and fail to load. To preserve ESM support, either emit the ESM bundle with a.mjsextension (and updateexports.import), or add adist/esm/package.jsonwith{ "type": "module" }during the build/publish step; alternatively, drop theimportcondition if ESM isn’t intended to be supported.
"main": "./dist/commonjs/index.js",
"exports": {
".": {
"import": "./dist/esm/index.js",
"require": "./dist/commonjs/index.js"
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Can you explain your intent with these changes? In particular:
|
|
The changes were done to appease Jest without using the experimental Jest ESM support. The recommended approach is to migrate to vitest. Should we do that instead? I think we're going to have to do that anyway (we already use it in the browser code -- which is going to be removed). |
This PR is preliminary to removing the browser code -- it involves some minor updates to configurations.