**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**
**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
This PR adds configurations files to `puppeteer`'s methods for
configuration. Under the hood, `puppeteer` relies on
https://www.npmjs.com/package/cosmiconfig which resolves several formats
of configuration:
- a `puppeteer` property in package.json
- a `.puppeteerrc` file in JSON or YAML format
- a `.puppeteerrc.json`, `.puppeteerrc.yaml`, `.puppeteerrc.yml`,
`.puppeteerrc.js`, or `.puppeteerrc.cjs` file
- a `puppeteer.config.js` or `puppeteer.config.cjs` CommonJS module
exporting an object
Documentation will be added later.
Fixed: #9128
This PR moves the puppeteer source code into separate mono-repo packages:
- `puppeteer` and `puppeteer-core` are now separated into their own
packages.
- `puppeteer-core` has a new exports called `puppeteer-core/internal`
for internal usage.
Tests and various tools have been updated to accommodate the migration.
This PR starts the monorepo migrations as per
https://github.com/puppeteer/puppeteer/issues/8922. To scope migrations,
we are only moving the `testserver` into a separate package. Further
migrations will come later.
This PR removes the manual vendoring process. Third party code can now
be updated using the typical NPM pipeline with types/code bundling done
through Rollup.
* chore: implement a test runner on top of mocha
This PR implements a test runner on top of mocha
that performs multiple mocha runs as defined in
TestSuites.json and compares the outcome of the runs
against TestExpectations.json. This allows us to
remove most of helpers from mocha-utils and be more
flexible when defining the test configurations.
pacakge-lock.json seems to be buggy now, with different OS giving different results.
See https://github.com/npm/npm/issues/17749
We have been having trouble keeping it up to date with yarn.lock. It doesn't give us a big win, because it is ignored if you install the package from npm.
This patch removes package-lock.json and starts ignoring it.
This patch re-introduces the DEBUG module to expose some of
the puppeteer's internals.
Currently, only the protocol message communication is exposed under
the 'puppeteer:protocol' namespace.
This patch implements documentation linter, which leaves under `test/doclint`
folder.
The documentation linter works like this:
1. Parse javascript source code with esprima and construct a "documentation" out of source code
2. Generate HTML out of `api.md` and traverse the HTML with puppeteer.
3. Make sure javascript aligns nicely with HTML
The documentation linter adds the following commands:
- `yarn doc` - to test that documentation covers all the relevant apis
- `yarn generate-toc` - to update the table-of-contents for the `api.md`
This patch:
- reformats codebase to use 2-spaces instead of 4. This will
align the project with other codebases (e.g. DevTools and Lighthouse)
- enables eslint indentation checking
References #19
This patch implements FrameManager which is responsible for maintaining
the frame tree. FrameManager is quite basic: it sends FrameAttached,
FrameDetached and FrameNavigated events, and can report mainFrame and
all frames.
The next step would be moving certain Page API's to the Frame. For
example, such method as Page.evaluate, Page.navigate and others should
be available on Frame object as well.
References #4
