Background
Split out from #411. While #411's reproduction (a transformer rewriting mutator.path) is being fixed as a bug, the comments raised a distinct, broader request: being able to point a mutator at an npm package instead of a local file.
It is not possible to use mutator from npm library.
— @aizerin, follow-up
This is filed as its own issue so it is not lost when the #411 bug fix lands, and because it is a feature (not a bug).
Current behavior
mutator: {
path: '@my-scope/axios',
name: 'useAxiosInstance',
}
fails with:
ENOENT: no such file or directory, open '.../@my-scope/axios'
Reproduced on orval v8.10.0.
Root cause:
normalizeMutator (packages/orval/src/utils/options.ts) always runs nodePath.resolve(workspace, path), turning a bare module specifier @my-scope/axios into <workspace>/@my-scope/axios.
generateMutator (packages/core/src/generators/mutator.ts) then does fs.readFile(importPath) on that non-existent path.
There is currently no way to consume a mutator that is published/shared as an npm package. The only workaround is require.resolve() + post-processing, as noted in the issue comments.
Problem
Teams that share a single HTTP client / mutator across multiple repositories want to distribute it as an npm package. Today they must vendor a local copy or post-process the generated output.
What to do
Support a bare module specifier as mutator.path:
- In
normalizeMutator: detect bare module specifiers (not relative .//../, not absolute) and keep path verbatim instead of resolving it against the workspace.
- In
generateMutator: for a bare specifier, resolve the real file for introspection (e.g. via require.resolve from the workspace) so numberOfParams / ErrorType / BodyType detection still works; emit the import path verbatim instead of computing a relative path.
getMutatorInfo's esbuild step already resolves bare entry points via node_modules (verified), so the introspection bundling itself needs no change.
- Document the npm-package mutator option in
docs/.../output.mdx.
Note: introspecting TypeScript-only types (ErrorType/BodyType) from a published package shipping compiled .js is inherently limited; that limitation is acceptable and should be documented.
Goal
mutator: { path: '@my-scope/axios', name: 'useAxiosInstance' } produces import { useAxiosInstance } from '@my-scope/axios' and generation succeeds.
- Works across all output modes (
single, split, tags, tags-split).
- Covered by tests and documented.
Background
Split out from #411. While #411's reproduction (a
transformerrewritingmutator.path) is being fixed as a bug, the comments raised a distinct, broader request: being able to point a mutator at an npm package instead of a local file.This is filed as its own issue so it is not lost when the #411 bug fix lands, and because it is a feature (not a bug).
Current behavior
fails with:
Reproduced on orval v8.10.0.
Root cause:
normalizeMutator(packages/orval/src/utils/options.ts) always runsnodePath.resolve(workspace, path), turning a bare module specifier@my-scope/axiosinto<workspace>/@my-scope/axios.generateMutator(packages/core/src/generators/mutator.ts) then doesfs.readFile(importPath)on that non-existent path.There is currently no way to consume a mutator that is published/shared as an npm package. The only workaround is
require.resolve()+ post-processing, as noted in the issue comments.Problem
Teams that share a single HTTP client / mutator across multiple repositories want to distribute it as an npm package. Today they must vendor a local copy or post-process the generated output.
What to do
Support a bare module specifier as
mutator.path:normalizeMutator: detect bare module specifiers (not relative.//../, not absolute) and keeppathverbatim instead of resolving it against the workspace.generateMutator: for a bare specifier, resolve the real file for introspection (e.g. viarequire.resolvefrom the workspace) sonumberOfParams/ErrorType/BodyTypedetection still works; emit the import path verbatim instead of computing a relative path.getMutatorInfo's esbuild step already resolves bare entry points vianode_modules(verified), so the introspection bundling itself needs no change.docs/.../output.mdx.Note: introspecting TypeScript-only types (
ErrorType/BodyType) from a published package shipping compiled.jsis inherently limited; that limitation is acceptable and should be documented.Goal
mutator: { path: '@my-scope/axios', name: 'useAxiosInstance' }producesimport { useAxiosInstance } from '@my-scope/axios'and generation succeeds.single,split,tags,tags-split).