**What kind of change does this PR introduce?**
Spawn own server when running `ng e2e`. Give user option to not replace
`ng e2e`.
**Did you add tests for your changes?**
Yes.
**If relevant, did you update the documentation?**
Yes, `ng-schematics` README.md updated.
**Summary**
When running `ng-schematics`'s `ng e2e` command spawns it's own server.
This way we remove the need of developers to run `ng server` separately
thus increasing ease of use in development and CI.
We want to support Protractor migration so we give the user the option
to opt out of replacing `ng e2e` so they can have a gradual migration.
(Note: There may be issues with folder conflicts, to be address in a PR
for adding better Migration support)
**Does this PR introduce a breaking change?**
Yes, as we don't check if required options are there before spawning the
server.
**Other information**
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
Removes `include-component-in-tag` from the release please config which
means that Puppeteer package releases will now be following the format
`puppeteer-vX.X.X`. Also, this PR updates the docker publishing action
to correctly parse such a tag to extract the `X.X.X` part, that is to be
used as the docker image label.
**What kind of change does this PR introduce?**
Better type inference.
**Did you add tests for your changes?**
~Not yet.~ Yes.
**If relevant, did you update the documentation?**
Not yet.
**Summary**
<!-- Explain the **motivation** for making this change. What existing
problem does the pull request solve? -->
<!-- Try to link to an open issue for more information. -->
Currently methods that return an element handle, i.e. `.$`,
`.waitForSelector` attempt to infer the node element type from the
selector string. However, this only works when the selector is an exact
match of the element tag, i.e. a selector `"a"` would be inferred as
`HTMLAnchorElement` . And not when the selector is complex, i.e.
selectors `"a#some-id"`, `div > a`, `a:nth-child(2)` would all fallback
on `Element`.
This is due to simply looking up the the selector in
`HTMLElementTagNameMap` and `SVGElementTagNameMap` without any attempt
to parse the selector string.
This PR is an attempt to do so.
**Does this PR introduce a breaking change?**
<!-- If this PR introduces a breaking change, please describe the impact
and a migration path for existing applications. -->
This could break existing incorrect assertions using the `as` keyword.
**Other information**
~This PR introduces a dependency on the `type-fest` package.~
This PR is far from complete (no tests, no docs). Put out early for
feedback and discussion.
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
**What kind of change does this PR introduce?**
This replaces the default `ng e2e` with our custom builder. In the
feature it seem possible to remove the necessity of the user running the
server separately and run it from the builder - that will improve the
easy of use and CI of this schematic.
**Did you add tests for your changes?**
**If relevant, did you update the documentation?**
Yes - Updated `@puppeteer/ng-schematics` README.md
**Summary**
We want to not see the default `ng e2e` and we want to make it easier
for the user to run commands.
Angular Developer are likely to also use its' CLI.
**Does this PR introduce a breaking change?**
Yes. Users need to delete the default and initialize the schematics
again.
**Other information**
The previous selector is broken as of ~2 months ago, c.f.
https://news.ycombinator.com/item?id=33027700
Changed from:
<a class="titlelink"></a>
To:
<span class="titleline">
<a></a>
</span>
**What kind of change does this PR introduce?**
Adds `@puppeteer/ng-schematics` to the list of packages to be published
to `npm`
**Did you add tests for your changes?**
Not relevant.
**If relevant, did you update the documentation?**
Not for in this PR.
**Summary**
We want to publish to `npm` so people can do `ng add
@puppeteer/ng-schematics` and use it with Angular CLI.
**Does this PR introduce a breaking change?**
No
**Other information**
**What kind of change does this PR introduce?**
It lets Users create an schematic for Puppeteer in Angular project using
Node's new test runner.
**Did you add tests for your changes?**
Yes. Unit test for module.
**If relevant, did you update the documentation?**
No
**Summary**
**Does this PR introduce a breaking change?**
No
**Other information**
**What kind of change does this PR introduce?**
Adds Mocha as option for `ng-schematics`
**Did you add tests for your changes?**
Yes
**If relevant, did you update the documentation?**
No
**Summary**
User want a simple solution for the Testing library of their choose
**Does this PR introduce a breaking change?**
No
**Other information**
There are some improvements around the Babel that we can make so we
don't have duplicate code and files (In a Feature PR)
**What kind of change does this PR introduce?**
Adds Jest in `ng-schematics`. So you can scaffold test with Jest instead
of Jasmine
**Did you add tests for your changes?**
Yes
**If relevant, did you update the documentation?**
No
**Summary**
Users can more easily integrate test with Puppeteer and their library of
choose.
**Does this PR introduce a breaking change?**
No
**Other information**
**What kind of change does this PR introduce?**
Add CI for testing Schematics.
**Did you add tests for your changes?**
Not relevant.
**If relevant, did you update the documentation?**
Not relevant.
**Summary**
We want to check if tests for `@puppeteer/ng-schematics` are passing
after
**Does this PR introduce a breaking change?**
No
**Other information**
**What kind of change does this PR introduce?**
It introduces schematic for Angular that integrate with its CLI.
First revision support Jasmine.
**Did you add tests for your changes?**
Added Unit tests for each scenario.
**Summary**
The idea is to provide a an example for setting up Puppeteer and Angular
for testing user flows.
**Does this PR introduce a breaking change?**
No
**Other information**
For Feature PRs:
- Introduce CL for tests
- Hook up NPM package publishing
- Update README.md
#8768 fixes flakiness in handling navigations but it didn't account for
the fact that subsequent navigation requests could be aborted via the
request interception. In that case, the navigationResponseReceived
promise would never be resolved. This PR adds a listener for the failed
network requests and resolves the promise if the network request has
failed. Adding test coverage for this seems tricky, as the reproduction
depends on timing of the second navigation request.
Closes#9175
<!-- Thanks for submitting a pull request! Please provide enough
information so that others can review your pull request. -->
**What kind of change does this PR introduce?**
- adds missing golden asset for firefox
**Summary**
- This change will let us see in mozilla ci, where we don't skip this
test, a better error message. Right now it fails with missing asset
error.
**Does this PR introduce a breaking change?**
no
