839dc1585b
We should be consistent about how options are defined in our plugins.
Currently, there are some options that use `enum`s and some that use
typed strings. I think typed strings are preferable because someone
extending a generator only needs to import the main generator that
they're extending, not all the transitive dependencies of that
generator.
Current extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
import { Linter } from '@nx/eslint';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: Linter.EsLint,
});
}
```
Desired extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: 'eslint',
});
}
```
The problem is not just an extra line of code, the person extending the
`reactApplicationGenerator` has to dig into the implementation details
of the generator itself in order to know where to find the `Linter`
enum. The `e2eTestRunner` is already a typed string and is easily
extended.
The solution I'm proposing in this PR would define a typed string in the
same file as the existing enum. None of the implementations need to
change. No community plugin code will be broken.
14 lines
334 B
TypeScript
14 lines
334 B
TypeScript
import { Linter, LinterType } from '@nx/eslint';
|
|
|
|
export interface StorybookConfigureSchema {
|
|
project: string;
|
|
interactionTests?: boolean;
|
|
generateStories?: boolean;
|
|
js?: boolean;
|
|
tsConfiguration?: boolean;
|
|
linter?: Linter | LinterType;
|
|
ignorePaths?: string[];
|
|
configureStaticServe?: boolean;
|
|
addPlugin?: boolean;
|
|
}
|