ardatan / ardatan/graphql-mesh
Support for ES Modules
- Dominant language
- TypeScript
- Stars
- 3.5k
- Forks
- 363
- Avg merge
- 6h 10m
- Merged PRs (30d)
- 19
Description
**Describe the bug**
Mesh errors on build once package.json contains `"type": "module`
```
Failed to generate schema: require() of ES Module .../graphql-mesh/examples/odata-msgraph-programmatic/.mesh/sources/Microsoft Graph/metadata.json.js from .../graphql-mesh/examples/odata-msgraph-programmatic/node_modules/@graphql-mesh/cli/bin.js not supported.
metadata.json.js is treated as an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which declares all .js files in that package scope as ES modules.
Instead rename metadata.json.js to end in .cjs, change the requiring code to use dynamic import() which is available in all CommonJS modules, or change "type": "module" to "type": "commonjs" in .../graphql-mesh/examples/odata-msgraph-programmatic/package.json to treat all .js files as CommonJS (using .mjs for all ES modules instead).
```
**To Reproduce**
Steps to reproduce the behavior:
1. Take an example from the repo, such as `odata-msgraph-programmatic`.
2. Add `"type": "module"` to the package.json
3. run `mesh build`
4. error thrown
**Expected behavior**
Build with no issues :)
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce the failure in examples/odata-msgraph-programmatic by adding "type": "module" to package.json and running mesh build. Start from @graphql-mesh/cli/bin.js and the generated metadata.json.js path; done means the example builds successfully with ES module mode enabled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, typescript
- Domain
- build-system, cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100