This PR updates app and lib generators in the following packages such
that they will generate files with the TS solution setup if it is
detected.
- `@nx/react`
- `@nx/next`
- `@nx/remix`
- `@nx/expo`
- `@nx/react-native`
React apps and libs will be linked using npm/pnpm/yarn/bun workspaces
feature rather than through tsconfig paths. This means that local
aliases like `@/` will work with Next.js and Remix apps.
Note: This will be behind `--workspaces` flag when using `npx
create-nx-workspace` and choosing React stack. If you use the None/TS
stack then adding plugins like `nx add @nx/react` then generating apps,
it will automatically pick up the new TS solution setup.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
React generators are not compatible with TS solution setup (i.e.
workspaces + TS project references).
## Expected Behavior
React generators work with new TS solution setup (Plain, Next.js, Remix,
Expo, React Native).
## Related Issue(s)
#28322
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
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.
* feat(testing): add generator to aid in the migration to cypress 10
cypress 10 introduces a new configuration format and new layout that requires update settings and
files for e2e projects
* feat(testing): cypress component tests for react/next
initial work for cypress component tests for react and next
* feat(testing): add support for v10 e2e cypress projects
create the correct files for cypress projects >v10 and reorganize tests based on version to allow
easier parsing of tests
* feat(testing): add utils for modifying cypress v10 config
provide ts transformers to take in an existing cypress config and update/add properties within the
given configuration
* fix(testing): fix tests affected by the cypress v10 changes
update tests to assert the correct files/folders/file contents due to the cypress changes in v10
* cleanup(testing): move cypress component testing plugins into the respective packages
move the plugins into out of cypress plugins into the specific vertical plugin to prevent issues
with circular refs
* cleanup(testing): bump cypress version
bump to latest cypress v10 release
* docs(testing): update docs for cypress 10
update cypress docs to include info about component testing and migration to cypress v10
* fix(repo): revert cypress version bump
keep v9 of cypress installed for nx repo until v10 release
* fix(testing): update cypress gen tsconfig and infer targets with converter
* fix(testing): make sure tests use the cypress v10 (for the intermediate)
* fix(testing): update target name after feedback
* fix(testing): support multiple target w/custom configs for cypress v10 migration
* fix(testing): refactor cy component tests into seperate verticals
* feat(testing): create storybook cypress preset
* fix(testing): clean up cy v10 migration
* fix(testing): don't branch for cypress executor testingType
* fix(testing): move cy comp test generator to next
* fix(testing): bump cypress deps
* fix(testing): clean up cy component testing generators
* fix(testing): update cy component testing docs
* fix(testign): dep check. runtime plugin pulls from @nrwl/react
* fix(testing): move e2e into verticals
* fix(testing): address PR feedback
* fix(testing): clean up unit tests
* feat(angular): support migrating angular cli workspaces using cypress v10
* chore(testing): update e2e tests
* fix(testing): address pr feedback
* chore(testing): remove cypress component testing for next.js
* fix(testing): address pr feedback
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
