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.
9 lines
509 B
TypeScript
9 lines
509 B
TypeScript
export { lintProjectGenerator } from './src/generators/lint-project/lint-project';
|
|
export { lintInitGenerator } from './src/generators/init/init';
|
|
export { Linter, LinterType } from './src/generators/utils/linter';
|
|
|
|
// @nx/angular needs it for the Angular CLI workspace migration to Nx to
|
|
// infer whether a config is using type aware rules and set the
|
|
// `hasTypeAwareRules` option of the `@nx/eslint:lint` executor.
|
|
export { hasRulesRequiringTypeChecking } from './src/utils/rules-requiring-type-checking';
|