Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(e2e): add support for puppteer v19 #3810

Merged
merged 13 commits into from Nov 29, 2022

Conversation

rwaskiewicz
Copy link
Member

@rwaskiewicz rwaskiewicz commented Nov 9, 2022

Pull request checklist

Please check if your PR fulfills the following requirements:

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been reviewed and added / updated if needed (for bug fixes / features) - docs(puppeteer): update support table stencil-site#932
  • Build (npm run build) was run locally and any changes were pushed
  • Unit tests (npm test) were run locally and passed
  • E2E Tests (npm run test.karma.prod) were run locally and passed
  • Prettier (npm run prettier) was run locally and passed

Pull request type

Please check the type of change your PR introduces:

  • Bugfix
  • Feature
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Other (please describe):

What is the current behavior?

GitHub Issue Number: N/A

What is the new behavior?

this pull request adds support for puppeteer v11 through v19.

each commit is described below:

Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

Puppeteer v14

the package is now declared in package.json using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript program that could not
be properly compiled/validated.

the moduleResolution and target fields needed to be explictly
set to allow the transpiled .d.ts to pass validation. this is a result
of cascading defaults where for the createProgram call:

  • the target field defaults to "ES3"
  • the target default causes the module field to default to
    "CommonJS"
  • the module default causes moduleResolution to default to
    "classic", which can't resolve the new type declaration file. as a
    result, we explicitly set this field
  • the target field is set to support the private identifiers in
    puppeteer
Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the evaluate() function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

Puppeteer v16

v16 did not require any changes in the codebase, other than incrementing
the list of supported versions of the library.

Puppeteer v17 this commit increments the supported version of puppeteer from v16 to v17.

puppeteer v17 made accessing a puppeteer ExecutionContext, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an ExecutionContext from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
ExecutionContext.

  1. ElementHandle Scenario

in this scenario, an ExecutionContext was being pulled off an
ElementHandle instance.

the suggested way of getting an ExecutionContext in puppeteer v17+ for
an ElementHandle is through the frame getter on the ElementHandle
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
executionContext() behavior. otherwise, the return value of the
frame getter is returned from a new utility method.

in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer package.json#version field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).

  1. JSHandle Scenario

accessing a JSHandle's ExecutionContext is necessary in
puppeteer-event.ts. because this is the only instance where stencil
would get an ExecutionContext from a JSHandle, no utility function
for retrieving an ExecutionContext was created. rather, the same
effect can be achieved in a backwards compatible way by calling
evaluate() directly on the JSHandle instance.

we do not call .asElement() on the JSHandle instance and
subsequently use the "ElementHandle Scenario" described above as a
JSHandle does not always have an element associated with it, making it
impossible to get an ExecutionContext in such instances

Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm

Does this introduce a breaking change?

  • Yes
  • No

Testing

This branch will be used for all manual testing.

Step 0 - Verify Type Checking on Stencil

Create test-pptr-w-tsc.sh in the root of the Stencil repo with the following contents:

#! /bin/bash
set -e

for VERSION in {10..19}
do
    npm i puppeteer@"${VERSION}"
    npm ci
    npm run clean
    npm run build
done

Run the script ./test-pptr-w-tsc.sh. This will verify that if we need to roll back the version of puppeteer, the code type checks in a backwards compatible way. Note, this step only checks the type checking, not the impl details of puppeteer and how they integrate with Stencil

Step 1 - Build this Branch

After completing Step 0, be sure to git reset --hard to restore anything that changed

To build it, checkout this branch and run the following:

npm ci && \
npm run clean && \
npm run build && \
npm pack

Note the path of the created tarball. We'll use that and refer to it as TARBALL_PATH

Step 2 - Smoke Test create-stencil Output

Create a small Stencil component library:

cd /tmp && \
npm init stencil component pptr && \
cd pptr && \
npm i && \
git init && \
git add -A && \
git commit -m 'init with cli'

In the root of the pptr/ dir, create test-version.sh with the following:

#! /bin/bash
set -e

if [ -z "$1" ]; then
    echo "Please provide the path to the tarball for Stencil"
    exit 1
fi

npm i "$1"
for VERSION in {10..19}
do
    npm i puppeteer@"${VERSION}"
    npm run test
done

Finally, run ./test-version.sh <TARBALL_PATH>. This will exercise the output of the create-stencil cli against the latest release for every major version of Puppeteer, starting with v10 and ending in v19. For all 10 versions, you should see something like:

> pptr@0.0.1 test
> stencil test --spec --e2e

[09:03.7]  @stencil/core
[09:03.9]  [LOCAL DEV] 🔋
[09:03.9]  testing e2e and spec files
[09:04.8]  build, pptr, dev mode, started ...
[09:04.8]  transpile started ...
[09:07.8]  transpile finished in 2.95 s
[09:07.8]  copy started ...
[09:07.8]  generate custom elements started ...
[09:07.8]  generate lazy started ...
[09:07.9]  copy finished (0 files) in 114 ms
[09:08.1]  generate custom elements finished in 317 ms
[09:08.1]  generate lazy finished in 316 ms
[09:08.1]  build finished in 3.36 s

[09:08.1]  jest args: --spec --e2e --max-workers=8
 PASS  src/utils/utils.spec.ts
 PASS  src/components/my-component/my-component.spec.ts
 PASS  src/components/my-component/my-component.e2e.ts

Test Suites: 3 passed, 3 total
Tests:       8 passed, 8 total
Snapshots:   0 total
Time:        1.673 s, estimated 2 s
Ran all test suites.

Step 3 - Test this Branch as a Drop-In Replacement for Stencil in Ionic Framework

Check out the Ionic Framework repository, and install this branch of Stencil in core.

cd core/ && \
npm i <PATH_TO_TARBALL>

We want to test that Puppeteer v10 works in the Ionic Framework with our changes from this branch applied. To do so, run the e2e tests:

npm run test.e2e

if everything passes, please move on to Step 4. It uses the work we just did.

Step 4 - This this Branch with Puppeteer v10->v19 in Ionic Framework

Before starting this step, complete all instructions for Step 3

In this step, we want to use the Ionic Framework as an example of a mature codebase using the E2E testing suite. We'll use a script to install each version of Puppeteer and run the test suite against our Stencil build and a specific version of Puppeteer.

To automate this process, create test-pptr-framework.sh in the core/ directory of the Ionic Framework repo you have:

#! /bin/bash
set -e

for VERSION in {10..19}
do
    npm i puppeteer@"${VERSION}"
    npm run test.e2e
done

And run it with ./test-pptr-framework.sh. The tests should pass for each version.

However! Please note:

  • This is a long running script 😅
  • I saw flakiness in v16 & v17 on the Ionic Framework. This appears to be intermittent, and resolved in v18, v19

Other information

Why Does this PR Target Stencil v3? Why Not Add this to v2?

Puppeteer v14 dropped support for Node 12, which Stencil v2 still supports. We still have users on Node 12 (as well as our CI pipeline testing against it for them), making it impossible to merge this without forcing it (and subsequent PRs) or removing Node 12 checks from the pipeline.

@github-actions
Copy link
Contributor

github-actions bot commented Nov 9, 2022

--strictNullChecks error report

Typechecking with --strictNullChecks resulted in 2142 errors on this branch.

That's 11 fewer than on main! 🎉🎉🎉

reports and statistics

Our most error-prone files
Path Error Count
src/compiler/config/test/validate-dev-server.spec.ts 45
src/compiler/config/test/validate-output-www.spec.ts 40
src/screenshot/connector-base.ts 40
src/dev-server/index.ts 38
src/mock-doc/serialize-node.ts 36
src/compiler/sys/tests/in-memory-fs.spec.ts 34
src/screenshot/screenshot-compare.ts 33
src/compiler/transformers/test/parse-props.spec.ts 32
src/dev-server/server-process.ts 32
src/runtime/vdom/vdom-render.ts 31
src/compiler/sys/typescript/typescript-config.ts 28
src/compiler/build/build-stats.ts 27
src/compiler/output-targets/dist-lazy/generate-lazy-module.ts 26
src/compiler/prerender/prerender-main.ts 25
src/sys/node/test/worker-manager.spec.ts 24
src/compiler/style/test/optimize-css.spec.ts 23
src/compiler/sys/in-memory-fs.ts 23
src/runtime/update-component.ts 23
src/testing/puppeteer/puppeteer-element.ts 23
src/compiler/config/test/validate-paths.spec.ts 22
Our most common errors
Typescript Error Code Count Error messages
TS2532 647
Error messages Object is possibly 'undefined'.
TS2345 609
Error messages Argument of type 'CompilerSystem | undefined' is not assignable to parameter of type 'CompilerSystem'.
Type 'undefined' is not assignable to type 'CompilerSystem'.

Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type 'Promise<(() => void) | null>' is not assignable to parameter of type 'Promise<() => void>'.

Argument of type 'null' is not assignable to parameter of type 'BuildResultsComponentGraph'.

Argument of type 'DevServerConfig | undefined' is not assignable to parameter of type 'StencilDevServerConfig'.
Type 'undefined' is not assignable to type 'StencilDevServerConfig'.

Argument of type 'Promise<(() => void) | null>' is not assignable to parameter of type 'Promise<() => void>'.
Type '(() => void) | null' is not assignable to type '() => void'.
Type 'null' is not assignable to type '() => void'.

Argument of type 'ComponentRuntimeHostListener[] | undefined' is not assignable to parameter of type 'ComponentRuntimeHostListener[]'.
Type 'undefined' is not assignable to type 'ComponentRuntimeHostListener[]'.

Argument of type 'HTMLScriptElement | null | undefined' is not assignable to parameter of type 'HTMLScriptElement'.
Type 'undefined' is not assignable to type 'HTMLScriptElement'.

Argument of type 'string | null' is not assignable to parameter of type 'string'.
Type 'null' is not assignable to type 'string'.

Argument of type 'Logger | undefined' is not assignable to parameter of type 'Logger'.
Type 'undefined' is not assignable to type 'Logger'.

Argument of type 'string[] | undefined' is not assignable to parameter of type 'string[]'.
Type 'undefined' is not assignable to type 'string[]'.

Argument of type 'string' is not assignable to parameter of type 'never'.

Argument of type 'Diagnostic[] | undefined' is not assignable to parameter of type 'readonly Diagnostic[]'.
Type 'undefined' is not assignable to type 'readonly Diagnostic[]'.

Argument of type 'boolean | undefined' is not assignable to parameter of type 'boolean'.

Argument of type 'BuildConditionals | undefined' is not assignable to parameter of type 'BuildConditionals'.
Type 'undefined' is not assignable to type 'BuildConditionals'.

Argument of type 'Diagnostic[] | undefined' is not assignable to parameter of type 'Diagnostic[]'.
Type 'undefined' is not assignable to type 'Diagnostic[]'.

Argument of type 'WorkerMeta | undefined' is not assignable to parameter of type 'WorkerMeta'.
Type 'undefined' is not assignable to type 'WorkerMeta'.

Argument of type 'string | null | undefined' is not assignable to parameter of type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type 'Set<string | null>' is not assignable to parameter of type 'Set'.
Type 'string | null' is not assignable to type 'string'.
Type 'null' is not assignable to type 'string'.

Argument of type 'Set<string | null>' is not assignable to parameter of type 'Set'.

Argument of type 'RollupConfig | undefined' is not assignable to parameter of type 'RollupConfig'.
Type 'undefined' is not assignable to type 'RollupConfig'.

Argument of type '(string[] | undefined)[]' is not assignable to parameter of type 'string[][]'.
Type 'string[] | undefined' is not assignable to type 'string[]'.
Type 'undefined' is not assignable to type 'string[]'.

Argument of type 'ComponentCompilerMeta | undefined' is not assignable to parameter of type 'ComponentCompilerMeta'.
Type 'undefined' is not assignable to type 'ComponentCompilerMeta'.

Argument of type 'true | Object | undefined' is not assignable to parameter of type 'boolean | Object | null'.
Type 'undefined' is not assignable to type 'boolean | Object | null'.

Argument of type 'SourceTarget | undefined' is not assignable to parameter of type 'SourceTarget'.
Type 'undefined' is not assignable to type 'SourceTarget'.

Argument of type 'boolean | undefined' is not assignable to parameter of type 'boolean'.
Type 'undefined' is not assignable to type 'boolean'.

Argument of type '(string | undefined)[]' is not assignable to parameter of type 'string[]'.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type '(string | undefined)[]' is not assignable to parameter of type 'string[]'.

Argument of type 'RollupSourceMap | undefined' is not assignable to parameter of type 'SourceMap'.
Type 'undefined' is not assignable to type 'SourceMap'.

Argument of type 'EntryModule | undefined' is not assignable to parameter of type 'EntryModule'.
Type 'undefined' is not assignable to type 'EntryModule'.

Argument of type '(Module | undefined)[]' is not assignable to parameter of type 'Module[]'.
Type 'Module | undefined' is not assignable to type 'Module'.
Type 'undefined' is not assignable to type 'Module'.

Argument of type 'Document | null' is not assignable to parameter of type 'Document'.
Type 'null' is not assignable to type 'Document'.

Argument of type 'Document | null' is not assignable to parameter of type 'Node | MockNode'.
Type 'null' is not assignable to type 'Node | MockNode'.

Argument of type 'HydrateAnchorElement' is not assignable to parameter of type '{ [attrName: string]: string; }'.
'string' index signatures are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type 'URL | null' is not assignable to parameter of type 'URL'.
Type 'null' is not assignable to type 'URL'.

Argument of type 'number | undefined' is not assignable to parameter of type 'number'.
Type 'undefined' is not assignable to type 'number'.

Argument of type 'SitemapXmpResults | null' is not assignable to parameter of type 'SitemapXmpResults'.
Type 'null' is not assignable to type 'SitemapXmpResults'.

Argument of type 'string | undefined' is not assignable to parameter of type 'string | URL'.

Argument of type 'Map<string, string[]> | undefined' is not assignable to parameter of type 'Map<string, string[]>'.
Type 'undefined' is not assignable to type 'Map<string, string[]>'.

Argument of type 'undefined' is not assignable to parameter of type 'string'.

Argument of type 'ServiceWorkerConfig | undefined' is not assignable to parameter of type 'ServiceWorkerConfig'.
Type 'undefined' is not assignable to type 'ServiceWorkerConfig'.

Argument of type 'string | undefined' is not assignable to parameter of type 'string | URL'.
Type 'undefined' is not assignable to type 'string | URL'.

Argument of type 'CssNode[] | null | undefined' is not assignable to parameter of type 'void | CssNode[]'.

Argument of type 'CssNode[] | null | undefined' is not assignable to parameter of type 'void | CssNode[]'.
Type 'null' is not assignable to type 'void | CssNode[]'.

Argument of type 'null' is not assignable to parameter of type 'string'.

Argument of type 'CompilerSystemCreateDirectoryOptions | undefined' is not assignable to parameter of type 'CompilerSystemCreateDirectoryOptions'.
Type 'undefined' is not assignable to type 'CompilerSystemCreateDirectoryOptions'.

Argument of type 'null' is not assignable to parameter of type 'CompilerFileWatcherEvent'.

Argument of type 'null' is not assignable to parameter of type '{ access: (filePath: string) => Promise; accessSync: (filePath: string) => boolean; cancelDeleteDirectoriesFromDisk: (dirPaths: string[]) => void; cancelDeleteFilesFromDisk: (filePaths: string[]) => void; ... 17 more ...; writeFiles: (files: { ...; } | Map<...>, opts?: FsWriteOptions | undefined) => Promise...'.

Argument of type 'undefined' is not assignable to parameter of type 'TypeChecker'.

Argument of type 'CollectionBundleManifest[] | undefined' is not assignable to parameter of type 'any[]'.
Type 'undefined' is not assignable to type 'any[]'.

Argument of type 'Module | undefined' is not assignable to parameter of type 'Module'.
Type 'undefined' is not assignable to type 'Module'.

Argument of type 'NodeArray | undefined' is not assignable to parameter of type 'NodeArray | HeritageClause[]'.
Type 'undefined' is not assignable to type 'NodeArray | HeritageClause[]'.

Argument of type 'Block | undefined' is not assignable to parameter of type 'Block'.
Type 'undefined' is not assignable to type 'Block'.

Argument of type 'undefined' is not assignable to parameter of type 'readonly ParameterDeclaration[]'.

Argument of type 'Expression | undefined' is not assignable to parameter of type 'Expression'.
Type 'undefined' is not assignable to type 'Expression'.

Argument of type 'Symbol | undefined' is not assignable to parameter of type 'Symbol'.
Type 'undefined' is not assignable to type 'Symbol'.

Argument of type 'TypeNode | undefined' is not assignable to parameter of type 'Node'.
Type 'undefined' is not assignable to type 'Node'.

Argument of type '(PropertyAssignment | null)[]' is not assignable to parameter of type 'readonly ObjectLiteralElementLike[]'.
Type 'PropertyAssignment | null' is not assignable to type 'ObjectLiteralElementLike'.
Type 'null' is not assignable to type 'ObjectLiteralElementLike'.

Argument of type 'Signature | undefined' is not assignable to parameter of type 'Signature'.
Type 'undefined' is not assignable to type 'Signature'.

Argument of type '(PropertyAssignment | null)[]' is not assignable to parameter of type 'readonly ObjectLiteralElementLike[]'.

Argument of type 'Identifier | undefined' is not assignable to parameter of type 'Node'.
Type 'undefined' is not assignable to type 'Node'.

Argument of type 'undefined' is not assignable to parameter of type 'readonly ClassElement[]'.

Argument of type 'Config | null | undefined' is not assignable to parameter of type 'Config'.
Type 'undefined' is not assignable to type 'Config'.

Argument of type 'null' is not assignable to parameter of type 'CollectionCompilerMeta'.

Argument of type 'PropertyName | undefined' is not assignable to parameter of type 'PropertyName'.
Type 'undefined' is not assignable to type 'PropertyName'.

Argument of type 'NamedExportBindings | undefined' is not assignable to parameter of type 'Node'.
Type 'undefined' is not assignable to type 'Node'.

Argument of type 'Declaration | undefined' is not assignable to parameter of type 'Node'.
Type 'undefined' is not assignable to type 'Node'.

Argument of type 'Identifier | undefined' is not assignable to parameter of type 'string | BindingName'.
Type 'undefined' is not assignable to type 'string | BindingName'.

Argument of type 'ScriptTarget | undefined' is not assignable to parameter of type 'ScriptTarget | CreateSourceFileOptions'.
Type 'undefined' is not assignable to type 'ScriptTarget | CreateSourceFileOptions'.

Argument of type 'Diagnostic' is not assignable to parameter of type 'DiagnosticWithLocation'.
Types of property 'file' are incompatible.
Type 'SourceFile | undefined' is not assignable to type 'SourceFile'.
Type 'undefined' is not assignable to type 'SourceFile'.

Argument of type '(...pathSegments: string[]) => string | undefined' is not assignable to parameter of type '(...args: string[]) => string'.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type 'OpenInEditorCallback | undefined' is not assignable to parameter of type 'OpenInEditorCallback'.
Type 'undefined' is not assignable to type 'OpenInEditorCallback'.

Argument of type 'CompilerWatcher | undefined' is not assignable to parameter of type 'CompilerWatcher'.
Type 'undefined' is not assignable to type 'CompilerWatcher'.

Argument of type '{ editor: string | undefined; }' is not assignable to parameter of type 'OpenInEditorOptions'.
Types of property 'editor' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type 'string | undefined' is not assignable to parameter of type 'PathLike'.

Argument of type 'DevServerConfig | undefined' is not assignable to parameter of type 'DevServerConfig'.
Type 'undefined' is not assignable to type 'DevServerConfig'.

Argument of type 'CompilerBuildResults | undefined' is not assignable to parameter of type 'CompilerBuildResults'.
Type 'undefined' is not assignable to type 'CompilerBuildResults'.

Argument of type 'Window | undefined' is not assignable to parameter of type 'Window'.
Type 'undefined' is not assignable to type 'Window'.

Argument of type 'SerializeDocumentOptions | undefined' is not assignable to parameter of type 'HydrateDocumentOptions'.
Type 'undefined' is not assignable to type 'HydrateDocumentOptions'.

Argument of type 'HydrateDocumentOptions | undefined' is not assignable to parameter of type 'HydrateDocumentOptions'.
Type 'undefined' is not assignable to type 'HydrateDocumentOptions'.

Argument of type 'MockNode | null' is not assignable to parameter of type 'MockNode'.
Type 'null' is not assignable to type 'MockNode'.

Argument of type 'string | undefined' is not assignable to parameter of type 'string | null'.
Type 'undefined' is not assignable to type 'string | null'.

Argument of type 'string | undefined' is not assignable to parameter of type 'string | null'.

Argument of type 'ShadowRoot | null' is not assignable to parameter of type 'Node'.
Type 'null' is not assignable to type 'Node'.

Argument of type 'MockElement' is not assignable to parameter of type 'MockHTMLElement'.
Types of property 'namespaceURI' are incompatible.
Type 'string | null' is not assignable to type 'string'.
Type 'null' is not assignable to type 'string'.

Argument of type 'null' is not assignable to parameter of type 'string | Node'.

Argument of type 'null' is not assignable to parameter of type 'string | boolean | undefined'.

Argument of type '(Window & typeof globalThis) | null' is not assignable to parameter of type 'Window'.
Type 'null' is not assignable to type 'Window'.

Argument of type 'string | null | undefined' is not assignable to parameter of type 'string | undefined'.

Argument of type 'HostRef | undefined' is not assignable to parameter of type 'HostRef'.
Type 'undefined' is not assignable to type 'HostRef'.

Argument of type 'this' is not assignable to parameter of type 'HostElement'.
Type 'HostElement' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/declarations/stencil-private").HostElement'.
The types returned by 'componentOnReady()' are incompatible between these types.
Type 'Promise | undefined' is not assignable to type 'Promise'.
Type 'undefined' is not assignable to type 'Promise'.

Argument of type 'this' is not assignable to parameter of type 'HostElement'.

Argument of type 'string | null' is not assignable to parameter of type 'string | undefined'.

Argument of type 'PropertyDescriptor | undefined' is not assignable to parameter of type 'PropertyDescriptor & ThisType'.
Type 'undefined' is not assignable to type 'PropertyDescriptor & ThisType'.
Type 'undefined' is not assignable to type 'PropertyDescriptor'.

Argument of type 'HTMLElement | undefined' is not assignable to parameter of type 'HTMLElement'.
Type 'undefined' is not assignable to type 'HTMLElement'.

Argument of type 'HostElement | undefined' is not assignable to parameter of type 'HostElement'.
Type 'undefined' is not assignable to type 'HostElement'.

Argument of type 'HostElement | undefined' is not assignable to parameter of type 'EventTarget'.
Type 'undefined' is not assignable to type 'EventTarget'.

Argument of type 'HostElement | undefined' is not assignable to parameter of type 'Element'.
Type 'undefined' is not assignable to type 'Element'.

Argument of type 'VNode[] | undefined' is not assignable to parameter of type 'VNode[]'.
Type 'undefined' is not assignable to type 'VNode[]'.

Argument of type 'null | undefined' is not assignable to parameter of type 'ChildType'.
Type 'undefined' is not assignable to type 'ChildType'.

Argument of type 'VNode | null' is not assignable to parameter of type 'ChildType'.
Type 'null' is not assignable to type 'ChildType'.

Argument of type 'VNode | undefined' is not assignable to parameter of type 'ChildType'.
Type 'undefined' is not assignable to type 'ChildType'.

Argument of type 'VNode | null | undefined' is not assignable to parameter of type 'ChildType'.
Type 'undefined' is not assignable to type 'ChildType'.

Argument of type 'null | undefined' is not assignable to parameter of type 'ChildType'.

Argument of type 'RenderNode | undefined' is not assignable to parameter of type 'Node | null'.
Type 'undefined' is not assignable to type 'Node | null'.

Argument of type 'VNode | undefined' is not assignable to parameter of type 'VNode'.
Type 'undefined' is not assignable to type 'VNode'.

Argument of type 'null' is not assignable to parameter of type 'VNode'.

Argument of type 'RenderNode | undefined' is not assignable to parameter of type 'Node'.
Type 'undefined' is not assignable to type 'Node'.

Argument of type 'null' is not assignable to parameter of type 'RenderNode'.

Argument of type 'ScreenshotDiff | undefined' is not assignable to parameter of type 'ScreenshotDiff'.
Type 'undefined' is not assignable to type 'ScreenshotDiff'.

Argument of type 'string | undefined' is not assignable to parameter of type 'PathLike'.
Type 'undefined' is not assignable to type 'PathLike'.

Argument of type 'string | undefined' is not assignable to parameter of type 'string | SemVer'.
Type 'undefined' is not assignable to type 'string | SemVer'.

Argument of type 'string | undefined' is not assignable to parameter of type 'string | SemVer'.

Argument of type 'null' is not assignable to parameter of type 'number | undefined'.

Argument of type 'null' is not assignable to parameter of type 'number | PromiseLike'.

Argument of type 'CompilerWorkerTask | undefined' is not assignable to parameter of type 'CompilerWorkerTask'.
Type 'undefined' is not assignable to type 'CompilerWorkerTask'.

Argument of type 'null' is not assignable to parameter of type 'CompilerWorkerTask'.

Argument of type 'undefined' is not assignable to parameter of type 'ErrorHandler'.

Argument of type 'string | undefined' is not assignable to parameter of type 'MockRequestInfo'.
Type 'undefined' is not assignable to type 'MockRequestInfo'.

Argument of type 'string | undefined' is not assignable to parameter of type 'MockRequestInfo'.

Argument of type 'MockResponse | undefined' is not assignable to parameter of type 'MockResponse'.
Type 'undefined' is not assignable to type 'MockResponse'.

Argument of type 'RuntimeRef | undefined' is not assignable to parameter of type 'RuntimeRef'.
Type 'undefined' is not assignable to type 'RuntimeRef'.

Argument of type 'this' is not assignable to parameter of type 'E2EElementInternal'.
Type 'E2EElement' is not assignable to type 'E2EElementInternal'.
Types of property 'find' are incompatible.
Type '(selector: string) => Promise<E2EElement | null>' is not assignable to type '(selector: FindSelector) => Promise'.

Argument of type '(elm: Element, pseudoElt: string) => any' is not assignable to parameter of type 'string | EvaluateFunc<[ElementHandle, string | null | undefined]>'.
Type '(elm: Element, pseudoElt: string) => any' is not assignable to type 'EvaluateFunc<[ElementHandle, string | null | undefined]>'.
Types of parameters 'pseudoElt' and 'params_1' are incompatible.
Type 'string | null | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type 'this' is not assignable to parameter of type 'E2EElementInternal'.

Argument of type '{ viewport: EmulateViewport | undefined; userAgent: string | undefined; }' is not assignable to parameter of type 'Device'.
Types of property 'userAgent' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Argument of type 'null' is not assignable to parameter of type 'SourceMap | undefined'.
TS2322 527
Error messages Type 'string | null | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type 'null' is not assignable to type 'DevServerConfig | undefined'.

Type 'boolean | null | undefined' is not assignable to type 'boolean | undefined'.
Type 'null' is not assignable to type 'boolean | undefined'.

Type 'null' is not assignable to type 'DevServer'.

Type 'undefined' is not assignable to type 'ComponentConstructor | Promise'.

Type 'HTMLElement | null' is not assignable to type 'HTMLElement'.
Type 'null' is not assignable to type 'HTMLElement'.

Type '({ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; } | { ...; })[]' is not assignable to type 'RollupResult[]'.
Type '{ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; } | { ...; }' is not assignable to type 'RollupResult'.
Type '{ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; }' is not assignable to type 'RollupResult'.
Type '{ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; }' is not assignable to type 'RollupChunkResult'.
Types of property 'moduleFormat' are incompatible.
Type 'ModuleFormat | undefined' is not assignable to type 'ModuleFormat'.
Type 'undefined' is not assignable to type 'ModuleFormat'.

Type 'null' is not assignable to type 'CompilerBuildResults'.

Type 'undefined' is not assignable to type 'string'.

Type 'null' is not assignable to type 'string'.

Type 'undefined' is not assignable to type 'Document'.

Type 'null' is not assignable to type 'Promise'.

Type 'null' is not assignable to type 'LoggerTimeSpan'.

Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type 'boolean | undefined' is not assignable to type 'boolean'.

Type 'number | undefined' is not assignable to type 'number'.
Type 'undefined' is not assignable to type 'number'.

Type 'boolean | "prod" | undefined' is not assignable to type 'boolean | "prod"'.
Type 'undefined' is not assignable to type 'boolean | "prod"'.

Type 'BuildResultsComponentGraph | undefined' is not assignable to type 'BuildResultsComponentGraph'.
Type 'undefined' is not assignable to type 'BuildResultsComponentGraph'.

Type 'RollupResults | undefined' is not assignable to type 'RollupResults'.
Type 'undefined' is not assignable to type 'RollupResults'.

Type '{ name: string | undefined; source: string; tags: any[]; }[]' is not assignable to type '{ name: string; source: string; tags: string[]; }[]'.
Type '{ name: string | undefined; source: string; tags: any[]; }' is not assignable to type '{ name: string; source: string; tags: string[]; }'.
Types of property 'name' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type 'null' is not assignable to type 'CompilerWorkerContext'.

Type 'null' is not assignable to type 'WatchOfConfigFile'.

Type 'null' is not assignable to type 'Promise<(void | void[])[]>'.

Type 'Promise<(void | void[] | null)[]>' is not assignable to type 'Promise<(void | void[])[]>'.
Type '(void | void[] | null)[]' is not assignable to type '(void | void[])[]'.
Type 'void | void[] | null' is not assignable to type 'void | void[]'.
Type 'null' is not assignable to type 'void | void[]'.

Type 'null' is not assignable to type '{ program: WatchOfConfigFile; rebuild: () => void; }'.

Type '(this: PluginContext, importee: string, importer: string) => Promise' is not assignable to type 'ResolveIdHook'.
Types of parameters 'importer' and 'importer' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type '(this: PluginContext, importee: string, importer: string) => Promise' is not assignable to type 'ResolveIdHook'.
Types of parameters 'importer' and 'importer' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type 'string | null' is not assignable to type 'string'.
Type 'null' is not assignable to type 'string'.

Type 'null' is not assignable to type 'string | undefined'.

Type 'string' is not assignable to type 'never'.

Type 'null' is not assignable to type 'never'.

Type 'never[]' is not assignable to type 'never'.

Type '{ code: string; exports: string[]; workerMsgId: string; dependencies: string[]; } | null' is not assignable to type 'WorkerMeta | undefined'.
Type 'null' is not assignable to type 'WorkerMeta | undefined'.

Type 'WorkerMeta | undefined' is not assignable to type 'WorkerMeta'.
Type 'undefined' is not assignable to type 'WorkerMeta'.

Type 'CompilerSystem | undefined' is not assignable to type 'CompilerSystem'.
Type 'undefined' is not assignable to type 'CompilerSystem'.

Type 'Logger | undefined' is not assignable to type 'Logger'.
Type 'undefined' is not assignable to type 'Logger'.

Type 'import("/home/runner/work/stencil/stencil/src/compiler/cache").Cache' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/declarations/stencil-private").Cache'.
The types returned by 'get(...)' are incompatible between these types.
Type 'Promise<string | null>' is not assignable to type 'Promise'.

Type 'null' is not assignable to type 'ValidatedConfig'.
Type 'null' is not assignable to type 'Config'.

Type 'null' is not assignable to type 'string[]'.

Type '{ dir: string; buildDir: string; collectionDir: string | null; typesDir: string; esmLoaderPath: string; copy: d.CopyTask[]; polyfills: boolean | undefined; empty: boolean; transformAliasedImportPathsInCollection: boolean; type: "dist"; }' is not assignable to type 'Required'.
Types of property 'polyfills' are incompatible.
Type 'boolean | undefined' is not assignable to type 'boolean'.

Type 'null' is not assignable to type 'number | undefined'.

Type 'null' is not assignable to type 'HistoryApiFallback | undefined'.

Type 'null' is not assignable to type 'CopyTask[] | undefined'.

Type '{ dirPath: string; filePath: string; fileName: string; readmePath: string; usagesDir: string; tag: string; readme: string | undefined; overview: string; usage: JsonDocsUsage; ... 13 more ...; listeners: JsonDocsListener[]; }[]' is not assignable to type 'JsonDocsComponent[]'.
Type '{ dirPath: string; filePath: string; fileName: string; readmePath: string; usagesDir: string; tag: string; readme: string | undefined; overview: string; usage: d.JsonDocsUsage; docs: string; ... 12 more ...; listeners: d.JsonDocsListener[]; }' is not assignable to type 'JsonDocsComponent'.
Types of property 'readme' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type 'string[] | undefined' is not assignable to type 'string[]'.
Type 'undefined' is not assignable to type 'string[]'.

Type '{ name: string; type: string; mutable: boolean; attr: string | undefined; reflectToAttr: boolean; docs: string; docsTags: CompilerJsDocTagInfo[]; default: string | undefined; deprecation: string | undefined; values: JsonDocsValue[]; optional: boolean; required: boolean; }[]' is not assignable to type 'JsonDocsProp[]'.
Type '{ name: string; type: string; mutable: boolean; attr: string | undefined; reflectToAttr: boolean; docs: string; docsTags: d.CompilerJsDocTagInfo[]; default: string | undefined; deprecation: string | undefined; values: d.JsonDocsValue[]; optional: boolean; required: boolean; }' is not assignable to type 'JsonDocsProp'.
Types of property 'default' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type '{ name: string; type: string; mutable: false; attr: string; reflectToAttr: false; docs: string; docsTags: never[]; default: undefined; deprecation: undefined; values: JsonDocsValue[]; optional: true; required: false; }[]' is not assignable to type 'JsonDocsProp[]'.
Type '{ name: string; type: string; mutable: false; attr: string; reflectToAttr: false; docs: string; docsTags: never[]; default: undefined; deprecation: undefined; values: d.JsonDocsValue[]; optional: true; required: false; }' is not assignable to type 'JsonDocsProp'.
Types of property 'default' are incompatible.
Type 'undefined' is not assignable to type 'string'.

Type '(ComponentCompilerMeta | undefined)[]' is not assignable to type 'ComponentCompilerMeta[]'.
Type 'ComponentCompilerMeta | undefined' is not assignable to type 'ComponentCompilerMeta'.
Type 'undefined' is not assignable to type 'ComponentCompilerMeta'.

Type '(ComponentCompilerMeta | undefined)[][]' is not assignable to type 'readonly ComponentCompilerMeta[][]'.
Type '(ComponentCompilerMeta | undefined)[]' is not assignable to type 'ComponentCompilerMeta[]'.

Type 'null' is not assignable to type 'boolean | SourceMapOptions | undefined'.

Type 'null' is not assignable to type 'SourceMap | undefined'.

Type '{ name: string | undefined; tags: string[]; }[]' is not assignable to type 'CollectionDependencyData[]'.
Type '{ name: string | undefined; tags: string[]; }' is not assignable to type 'CollectionDependencyData'.
Types of property 'name' are incompatible.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type 'string | undefined' is not assignable to type 'string | number'.
Type 'undefined' is not assignable to type 'string | number'.

Type 'SourceMap | undefined' is not assignable to type 'SourceMap'.
Type 'undefined' is not assignable to type 'SourceMap'.

Type 'string | null' is not assignable to type 'string | undefined'.
Type 'null' is not assignable to type 'string | undefined'.

Type 'null' is not assignable to type 'Function'.

Type 'null' is not assignable to type 'Map<string, string[]>'.

Type 'null' is not assignable to type 'PrerenderConfig'.

Type 'null' is not assignable to type 'Set'.

Type 'null' is not assignable to type 'HydrateAnchorElement[]'.

Type 'null' is not assignable to type '(prerenderRequest: PrerenderUrlRequest) => Promise'.

Type 'CssNode | null' is not assignable to type 'void | CssNode'.
Type 'null' is not assignable to type 'void | CssNode'.

Type 'CssNode | null' is not assignable to type 'CssNode'.
Type 'null' is not assignable to type 'CssNode'.

Type 'CssNode | null' is not assignable to type 'void | CssNode'.

Type 'RegExpExecArray | null' is not assignable to type 'RegExpExecArray'.
Type 'null' is not assignable to type 'RegExpExecArray'.

Type 'null' is not assignable to type '() => string'.

Type 'null' is not assignable to type 'number'.

Type 'null' is not assignable to type 'boolean'.

Type 'null' is not assignable to type 'boolean | undefined'.

Type 'FsItem | undefined' is not assignable to type 'FsItem'.
Type 'undefined' is not assignable to type 'FsItem'.

Type 'null' is not assignable to type 'CompilerFileWatcherCallback[]'.

Type '(key: string) => string | undefined' is not assignable to type '(key: string) => string'.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type '(p: string) => Promise<string | undefined>' is not assignable to type '{ (p: string): Promise; (p: string, encoding: "utf8"): Promise; (p: string, encoding: "binary"): Promise; }'.
Type 'Promise<string | undefined>' is not assignable to type 'Promise'.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type '(p: string) => string | undefined' is not assignable to type '(p: string, encoding?: string | undefined) => string'.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type '((maxConcurrentWorkers: number) => WorkerMainController) | null' is not assignable to type '((maxConcurrentWorkers: number) => WorkerMainController) | undefined'.
Type 'null' is not assignable to type '((maxConcurrentWorkers: number) => WorkerMainController) | undefined'.

Type 'null' is not assignable to type 'ResolvedModuleWithFailedLookupLocations'.

Type 'null' is not assignable to type 'Worker'.

Type 'CollectionCompilerMeta | undefined' is not assignable to type 'CollectionCompilerMeta'.
Type 'undefined' is not assignable to type 'CollectionCompilerMeta'.

Type 'DeclarationName | undefined' is not assignable to type 'DeclarationName'.
Type 'undefined' is not assignable to type 'DeclarationName'.

Type 'null' is not assignable to type 'PropertyAssignment'.

Type 'boolean | null' is not assignable to type 'boolean'.
Type 'null' is not assignable to type 'boolean'.

Type 'undefined' is not assignable to type 'ComponentCompilerVirtualProperty'.

Type '{ name: string; method: string; bubbles: boolean; cancelable: boolean; composed: boolean; docs: CompilerJsDoc; complexType: ComponentCompilerEventComplexType; internal: boolean | undefined; }[]' is not assignable to type 'ComponentCompilerEvent[]'.
Type '{ name: string; method: string; bubbles: boolean; cancelable: boolean; composed: boolean; docs: d.CompilerJsDoc; complexType: d.ComponentCompilerEventComplexType; internal: boolean | undefined; }' is not assignable to type 'ComponentCompilerEvent'.
Types of property 'internal' are incompatible.
Type 'boolean | undefined' is not assignable to type 'boolean'.

Type '{ name: string; docs: CompilerJsDoc; complexType: ComponentCompilerMethodComplexType; internal: boolean | undefined; }[]' is not assignable to type 'ComponentCompilerMethod[]'.
Type '{ name: string; docs: d.CompilerJsDoc; complexType: d.ComponentCompilerMethodComplexType; internal: boolean | undefined; }' is not assignable to type 'ComponentCompilerMethod'.
Types of property 'internal' are incompatible.
Type 'boolean | undefined' is not assignable to type 'boolean'.

Type '{ name: string; type: ComponentCompilerPropertyType; attribute: string | undefined; reflect: boolean; mutable: boolean; required: boolean; optional: boolean; defaultValue: string | undefined; complexType: ComponentCompilerPropertyComplexType; docs: CompilerJsDoc; internal: boolean | undefined; }[]' is not assignable to type 'ComponentCompilerProperty[]'.
Type '{ name: string; type: d.ComponentCompilerPropertyType; attribute: string | undefined; reflect: boolean; mutable: boolean; required: boolean; optional: boolean; defaultValue: string | undefined; complexType: d.ComponentCompilerPropertyComplexType; docs: d.CompilerJsDoc; internal: boolean | undefined; }' is not assignable to type 'ComponentCompilerProperty'.
Types of property 'internal' are incompatible.
Type 'boolean | undefined' is not assignable to type 'boolean'.

Type 'null' is not assignable to type 'ImportData'.

Type 'undefined' is not assignable to type '"queryparams" | null'.

Type 'null' is not assignable to type 'WeakSet'.

Type 'null' is not assignable to type 'Module'.

Type 'Module | undefined' is not assignable to type 'Module'.
Type 'undefined' is not assignable to type 'Module'.

Type 'undefined' is not assignable to type 'CompilerJsDoc'.

Type '{ [x: string]: d.TypesMemberNameData[] | undefined; }' is not assignable to type 'TypesImportData'.
'string' index signatures are incompatible.
Type 'TypesMemberNameData[] | undefined' is not assignable to type 'TypesMemberNameData[]'.
Type 'undefined' is not assignable to type 'TypesMemberNameData[]'.

Type 'string | undefined' is not assignable to type 'string | null'.

Type '((data: { file: string; line: number; column: number; }) => void) | null' is not assignable to type 'OpenInEditorCallback | undefined'.
Type 'null' is not assignable to type 'OpenInEditorCallback | undefined'.

Type 'null' is not assignable to type 'WebSocket'.

Type 'null' is not assignable to type 'BuildOnEventRemove'.

Type 'null' is not assignable to type '() => void'.

Type 'null' is not assignable to type '(msg: DevServerMessage) => void'.

Type 'DevServerConfig | undefined' is not assignable to type 'DevServerConfig'.
Type 'undefined' is not assignable to type 'DevServerConfig'.

Type 'null' is not assignable to type '{ open(openId: string): Promise; }'.

Type 'string | null' is not assignable to type 'string | undefined'.

Type 'null' is not assignable to type 'Promise<DevServerEditor[]>'.

Type 'null' is not assignable to type '(req: IncomingMessage, res: ServerResponse, next: () => void) => void'.

Type 'null' is not assignable to type 'URL'.

Type 'null' is not assignable to type 'URLSearchParams'.

Type 'PageReloadStrategy | undefined' is not assignable to type 'PageReloadStrategy'.
Type 'undefined' is not assignable to type 'PageReloadStrategy'.

Type 'null' is not assignable to type 'Server<typeof IncomingMessage, typeof ServerResponse>'.

Type 'null' is not assignable to type 'DevWebSocket'.

Type 'null' is not assignable to type 'DevServerContext'.

Type 'DevWebSocket | null' is not assignable to type 'DevWebSocket'.
Type 'null' is not assignable to type 'DevWebSocket'.

Type 'null' is not assignable to type 'ChildProcess'.

Type 'null' is not assignable to type 'HydrateApp'.

Type '() => undefined' is not assignable to type '{ (cb?: (() => void) | undefined): TestServerResponse; (chunk: any, cb?: (() => void) | undefined): TestServerResponse; (chunk: any, encoding: BufferEncoding, cb?: (() => void) | undefined): TestServerResponse; }'.
Type 'undefined' is not assignable to type 'TestServerResponse'.

Type 'null' is not assignable to type 'ComponentConstructor'.

Type '(this: HostElement) => Promise | undefined' is not assignable to type '() => Promise'.
Type 'Promise | undefined' is not assignable to type 'Promise'.
Type 'undefined' is not assignable to type 'Promise'.

Type 'null' is not assignable to type 'Window & typeof globalThis'.
Type 'null' is not assignable to type 'Window'.

Type 'null' is not assignable to type 'Window & typeof globalThis'.

Type 'null' is not assignable to type 'MockCSSStyleSheet'.

Type 'null' is not assignable to type 'string | boolean'.

Type 'null' is not assignable to type 'Location'.

Type 'null' is not assignable to type 'MockElement'.

Type 'null' is not assignable to type 'SVGSVGElement'.

Type 'null' is not assignable to type 'SVGElement'.

Type 'null' is not assignable to type 'EventTarget'.

Type 'null' is not assignable to type 'MockEventListener[]'.

Type 'null' is not assignable to type 'MockDocument'.

Type '{ name: string; value: string; namespace: string | null; prefix: null; }[]' is not assignable to type 'Attribute[]'.
Type '{ name: string; value: string; namespace: string | null; prefix: null; }' is not assignable to type 'Attribute'.
Types of property 'namespace' are incompatible.
Type 'string | null' is not assignable to type 'string | undefined'.

Type '(element: MockElement) => string | null' is not assignable to type '(element: unknown) => string'.
Type 'string | null' is not assignable to type 'string'.
Type 'null' is not assignable to type 'string'.

Type 'ParentNode | null' is not assignable to type 'Node'.
Type 'null' is not assignable to type 'Node'.

Type 'null' is not assignable to type 'Document'.

Type 'string | null | undefined' is not assignable to type 'string | undefined'.

Type 'never[] | null' is not assignable to type 'RenderNode[]'.
Type 'null' is not assignable to type 'RenderNode[]'.

Type 'null' is not assignable to type 'VNode[]'.

Type 'null' is not assignable to type 'string | number | undefined'.

Type 'null' is not assignable to type 'string | number | Function'.

Type 'RenderNode | null' is not assignable to type 'RenderNode'.
Type 'null' is not assignable to type 'RenderNode'.

Type 'HTMLElement | null' is not assignable to type 'EventTarget'.
Type 'null' is not assignable to type 'EventTarget'.

Type 'string | null | undefined' is not assignable to type 'string | undefined'.
Type 'null' is not assignable to type 'string | undefined'.

Type 'null' is not assignable to type 'Set | undefined'.

Type 'null' is not assignable to type '[string, any][] | undefined'.

Type 'VNode[] | undefined' is not assignable to type 'VNode[]'.
Type 'undefined' is not assignable to type 'VNode[]'.

Type '(props: {}, children: VNode[], utils: FunctionalUtilities) => null' is not assignable to type 'FunctionalComponent<{}>'.
Type 'null' is not assignable to type 'VNode | VNode[]'.

Type '() => null' is not assignable to type 'FunctionalComponent<{}>'.
Type 'null' is not assignable to type 'VNode | VNode[]'.

Type 'null' is not assignable to type 'VNode'.

Type 'undefined' is not assignable to type 'VNode'.

Type 'RenderNode | undefined' is not assignable to type 'RenderNode'.
Type 'undefined' is not assignable to type 'RenderNode'.

Type 'RelocateNodeData | undefined' is not assignable to type 'RelocateNodeData'.
Type 'undefined' is not assignable to type 'RelocateNodeData'.

Type 'ChildNode | null' is not assignable to type 'Node'.
Type 'null' is not assignable to type 'Node'.

Type 'null' is not assignable to type 'ScreenshotBuild'.

Type 'null' is not assignable to type 'ScreenshotCache'.

Type 'null' is not assignable to type 'Buffer'.

Type 'null' is not assignable to type 'Screenshot'.

Type '(() => void) | undefined' is not assignable to type '() => any'.
Type 'undefined' is not assignable to type '() => any'.

Type '() => null' is not assignable to type '(opts: { rootDir: string; moduleId: string; path: string; }) => string'.
Type 'null' is not assignable to type 'string'.

Type '() => null' is not assignable to type '(opts: { moduleId: string; path?: string | undefined; version?: string | undefined; }) => string'.
Type 'null' is not assignable to type 'string'.

Type '() => string | undefined' is not assignable to type '() => string'.
Type 'string | undefined' is not assignable to type 'string'.
Type 'undefined' is not assignable to type 'string'.

Type 'number | null' is not assignable to type 'number'.
Type 'null' is not assignable to type 'number'.

Type 'any[] | undefined' is not assignable to type 'any[]'.
Type 'undefined' is not assignable to type 'any[]'.

Type 'boolean | null | undefined' is not assignable to type 'boolean | undefined'.

Type 'null' is not assignable to type 'ConfigBundle[] | undefined'.

Type 'null' is not assignable to type 'OutputTarget[] | undefined'.

Type 'null' is not assignable to type 'TestingConfig | undefined'.

Type 'null' is not assignable to type 'Cache'.

Type 'null' is not assignable to type '{ access: (filePath: string) => Promise; accessSync: (filePath: string) => boolean; cancelDeleteDirectoriesFromDisk: (dirPaths: string[]) => void; cancelDeleteFilesFromDisk: (filePaths: string[]) => void; ... 17 more ...; writeFiles: (files: { ...; } | Map<...>, opts?: FsWriteOptions | undefined) => Promise...'.

Type 'HostRef | undefined' is not assignable to type 'HostRef'.
Type 'undefined' is not assignable to type 'HostRef'.

Type 'Function | undefined' is not assignable to type 'Function'.
Type 'undefined' is not assignable to type 'Function'.

Type 'RafCallback | undefined' is not assignable to type 'Function'.
Type 'undefined' is not assignable to type 'Function'.

Type 'QueuedLoadModule | undefined' is not assignable to type 'QueuedLoadModule'.
Type 'undefined' is not assignable to type 'QueuedLoadModule'.

Type 'null' is not assignable to type 'ElementHandle'.

Type 'null' is not assignable to type 'E2EPageInternal'.

Type 'ElementHandle | null' is not assignable to type 'ElementHandle'.
Type 'null' is not assignable to type 'ElementHandle'.

Type 'ElementHandle | null' is not assignable to type 'ElementHandle'.
Type 'null' is not assignable to type 'ElementHandle'.

Type 'ElementHandle | null' is not assignable to type 'ElementHandle | null'.
Type 'ElementHandle' is not assignable to type 'ElementHandle'.
Type 'Node' is missing the following properties from type 'Element': attributes, classList, className, clientHeight, and 110 more.

Type 'null' is not assignable to type 'Promise<JSHandle>'.

Type '(a?: any, b?: any) => Promise<ScreenshotDiff | undefined>' is not assignable to type '{ (): Promise; (description: string): Promise; (opts: ScreenshotOptions): Promise<...>; (description: string, opts: ScreenshotOptions): Promise<...>; }'.
Type 'Promise<ScreenshotDiff | undefined>' is not assignable to type 'Promise'.
Type 'ScreenshotDiff | undefined' is not assignable to type 'ScreenshotDiff'.
Type 'undefined' is not assignable to type 'ScreenshotDiff'.

Type 'null' is not assignable to type 'CompilerWatcher'.

Type 'null' is not assignable to type 'Promise'.

Type 'Browser | null' is not assignable to type 'Browser'.
Type 'null' is not assignable to type 'Browser'.

Type 'null' is not assignable to type 'ValidatedConfig'.

Type 'null' is not assignable to type 'Browser'.

Type 'null' is not assignable to type 'SourceMap'.

Type 'null' is not assignable to type 'PackageJsonData'.

Type 'null' is not assignable to type '{ [moduleId: string]: string; } | undefined'.
TS2531 203
Error messages Object is possibly 'null'.
TS2454 46
Error messages Variable 'pkgJsonData' is used before being assigned.

Variable 'minifyOpts' is used before being assigned.

Variable 'workerCtrl' is used before being assigned.

Variable 'timespan' is used before being assigned.

Variable 'content' is used before being assigned.

Variable 'compilerExe' is used before being assigned.

Variable 'outputText' is used before being assigned.

Variable 'importResolvedFile' is used before being assigned.

Variable 'win' is used before being assigned.

Variable 'attrName' is used before being assigned.

Variable 'oldValue' is used before being assigned.

Variable 'newValue' is used before being assigned.

Variable 'hostId' is used before being assigned.

Variable 'promise' is used before being assigned.

Variable 'textContent' is used before being assigned.

Variable 'resolve' is used before being assigned.

Variable 'opts' is used before being assigned.
TS2722 41
Error messages Cannot invoke an object which is possibly 'undefined'.
TS2352 19
Error messages Conversion of type 'null' to type 'CompilerSystem' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

Conversion of type 'null' to type 'string' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

Conversion of type 'null' to type 'string[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

Conversion of type '{ cmps: never[]; }' to type 'Module' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
Type '{ cmps: never[]; }' is missing the following properties from type 'Module': coreRuntimeApis, collectionName, dtsFilePath, excludeFromCollection, and 27 more.

Conversion of type 'null' to type 'ScreenshotCache' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
TS2769 12
Error messages No overload matches this call.
Overload 1 of 2, '(type: keyof DocumentEventMap, listener: (this: Document, ev: PointerEvent | MouseEvent | UIEvent | Event | ErrorEvent | ... 13 more ... | WheelEvent) => any, options?: boolean | ... 1 more ... | undefined): void', gave the following error.
Argument of type '"e"' is not assignable to parameter of type 'keyof DocumentEventMap'.
Overload 2 of 2, '(type: string, listener: EventListenerOrEventListenerObject, options?: boolean | AddEventListenerOptions | undefined): void', gave the following error.
Argument of type 'null' is not assignable to parameter of type 'EventListenerOrEventListenerObject'.

No overload matches this call.
Overload 1 of 2, '(o: {}): string[]', gave the following error.
Argument of type 'BuildResultsComponentGraph | undefined' is not assignable to parameter of type '{}'.
Type 'undefined' is not assignable to type '{}'.
Overload 2 of 2, '(o: object): string[]', gave the following error.
Argument of type 'BuildResultsComponentGraph | undefined' is not assignable to parameter of type 'object'.
Type 'undefined' is not assignable to type 'object'.

No overload matches this call.
Overload 1 of 4, '(object: {}, method: never): SpyInstance<never, never>', gave the following error.
Argument of type 'CompilerWorkerContext | undefined' is not assignable to parameter of type '{}'.
Type 'undefined' is not assignable to type '{}'.
Overload 2 of 4, '(object: {}, method: never): SpyInstance<never, never>', gave the following error.
Argument of type 'CompilerWorkerContext | undefined' is not assignable to parameter of type '{}'.
Type 'undefined' is not assignable to type '{}'.

No overload matches this call.
The last overload gave the following error.
Argument of type 'string | null' is not assignable to parameter of type '(substring: string, ...args: any[]) => string'.
Type 'null' is not assignable to type '(substring: string, ...args: any[]) => string'.

No overload matches this call.
The last overload gave the following error.
Argument of type 'string | undefined' is not assignable to parameter of type 'string | RegExp'.
Type 'undefined' is not assignable to type 'string | RegExp'.

No overload matches this call.
Overload 1 of 2, '(configFileName: string, optionsToExtend: CompilerOptions | undefined, system: System, createProgram?: CreateProgram | undefined, reportDiagnostic?: DiagnosticReporter | undefined, reportWatchStatus?: WatchStatusReporter | undefined, watchOptionsToExtend?: WatchOptions | undefined, extraFileExtensions?: readonly FileExtensionInfo[] | undefined): WatchCompilerHostOfConfigFile<...>', gave the following error.
Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
Type 'undefined' is not assignable to type 'string'.
Overload 2 of 2, '(rootFiles: string[], options: CompilerOptions, system: System, createProgram?: CreateProgram | undefined, reportDiagnostic?: DiagnosticReporter | undefined, reportWatchStatus?: WatchStatusReporter | undefined, projectReferences?: readonly ProjectReference[] | undefined, watchOptions?: WatchOptions | undefined): WatchCompilerHostOfFilesAndCompilerOptions<...>', gave the following error.
Argument of type 'string | undefined' is not assignable to parameter of type 'string[]'.
Type 'undefined' is not assignable to type 'string[]'.

No overload matches this call.
Overload 1 of 2, '(timeoutId: string | number | Timeout | undefined): void', gave the following error.
Argument of type 'Timeout | null' is not assignable to parameter of type 'string | number | Timeout | undefined'.
Type 'null' is not assignable to type 'string | number | Timeout | undefined'.
Overload 2 of 2, '(id?: number | undefined): void', gave the following error.
Argument of type 'Timeout | null' is not assignable to parameter of type 'number | undefined'.
Type 'null' is not assignable to type 'number | undefined'.

No overload matches this call.
Overload 1 of 2, '(timeoutId: string | number | Timeout | undefined): void', gave the following error.
Argument of type 'Timeout | null' is not assignable to parameter of type 'string | number | Timeout | undefined'.
Overload 2 of 2, '(id?: number | undefined): void', gave the following error.
Argument of type 'Timeout | null' is not assignable to parameter of type 'number | undefined'.

No overload matches this call.
Overload 1 of 3, '(p: string, encoding: "utf8"): Promise', gave the following error.
Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
Type 'undefined' is not assignable to type 'string'.
Overload 2 of 3, '(p: string, encoding: "binary"): Promise', gave the following error.
Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
Type 'undefined' is not assignable to type 'string'.

No overload matches this call.
Overload 1 of 2, '(values: [] | readonly unknown[]): Promise<unknown[] | []>', gave the following error.
Argument of type 'Promise[] | undefined' is not assignable to parameter of type '[] | readonly unknown[]'.
Type 'undefined' is not assignable to type '[] | readonly unknown[]'.
Overload 2 of 2, '(values: Iterable<void | PromiseLike>): Promise<void[]>', gave the following error.
Argument of type 'Promise[] | undefined' is not assignable to parameter of type 'Iterable<void | PromiseLike>'.
Type 'undefined' is not assignable to type 'Iterable<void | PromiseLike>'.
TS2790 10
Error messages The operand of a 'delete' operator must be optional.
TS2538 8
Error messages Type 'undefined' cannot be used as an index type.

Type 'null' cannot be used as an index type.
TS2416 5
Error messages Property 'get' in type 'Cache' is not assignable to the same property in base type 'Cache'.
Type '(key: string) => Promise<string | null>' is not assignable to type '(key: string) => Promise'.
Type 'Promise<string | null>' is not assignable to type 'Promise'.
Type 'string | null' is not assignable to type 'string'.
Type 'null' is not assignable to type 'string'.

Property 'getMemoryStats' in type 'Cache' is not assignable to the same property in base type 'Cache'.
Type '() => string | null' is not assignable to type '() => string'.
Type 'string | null' is not assignable to type 'string'.
Type 'null' is not assignable to type 'string'.

Property 'find' in type 'E2EElement' is not assignable to the same property in base type 'E2EElementInternal'.
Type '(selector: string) => Promise<E2EElement | null>' is not assignable to type '(selector: FindSelector) => Promise'.
Type 'Promise<E2EElement | null>' is not assignable to type 'Promise'.
Type 'E2EElement | null' is not assignable to type 'E2EElement'.
Type 'null' is not assignable to type 'E2EElement'.

Property 'findAll' in type 'E2EElement' is not assignable to the same property in base type 'E2EElementInternal'.
Type '(selector: string) => Promise<E2EElement[]>' is not assignable to type '(selector: FindSelector) => Promise<E2EElement[]>'.
Type 'Promise<import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-element").E2EElement[]>' is not assignable to type 'Promise<import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-declarations").E2EElement[]>'.
Type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-element").E2EElement[]' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-declarations").E2EElement[]'.
Type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-element").E2EElement' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-declarations").E2EElement'.
The types returned by 'find(...)' are incompatible between these types.
Type 'Promise<E2EElement | null>' is not assignable to type 'Promise'.

Property 'getComputedStyle' in type 'E2EElement' is not assignable to the same property in base type 'E2EElementInternal'.
Type '(pseudoElt?: string | null | undefined) => Promise' is not assignable to type '(pseudoElt?: string | null | undefined) => Promise'.
Type 'Promise' is not assignable to type 'Promise'.
Type 'unknown' is not assignable to type 'CSSStyleDeclaration'.
TS2533 3
Error messages Object is possibly 'null' or 'undefined'.
TS2493 3
Error messages Tuple type '[]' of length '0' has no element at index '0'.
TS2488 2
Error messages Type 'Diagnostic[] | undefined' must have a 'Symbol.iterator' method that returns an iterator.

Type 'string[] | undefined' must have a 'Symbol.iterator' method that returns an iterator.
TS2774 2
Error messages This condition will always return true since this function is always defined. Did you mean to call it instead?
TS2571 2
Error messages Object is of type 'unknown'.
TS2684 1
Error messages The 'this' context of type 'ResolveIdHook | undefined' is not assignable to method's 'this' of type 'Function'.
Type 'undefined' is not assignable to type 'Function'.
TS2464 1
Error messages A computed property name must be of type 'string', 'number', 'symbol', or 'any'.
TS2430 1
Error messages Interface 'SerializeOpts' incorrectly extends interface 'SerializeCssOptions'.
Types of property 'usedSelectors' are incompatible.
Type 'UsedSelectors | null' is not assignable to type 'UsedSelectors | undefined'.
Type 'null' is not assignable to type 'UsedSelectors | undefined'.

Unused exports report

There are 9 unused exports on this PR. That's the same number of errors on main, so at least we're not creating new ones!

Unused exports
File Line Identifier
src/screenshot/screenshot-fs.ts 18 readScreenshotData
src/testing/testing-utils.ts 186 withSilentWarn
src/compiler/app-core/app-data.ts 3 BUILD
src/compiler/app-core/app-data.ts 88 Env
src/compiler/app-core/app-data.ts 90 NAMESPACE
src/compiler/fs-watch/fs-watch-rebuild.ts 111 updateCacheFromRebuild
src/testing/platform/testing-platform.ts 29 cssVarShim
src/testing/puppeteer/puppeteer-declarations.ts 485 WaitForEventOptions
src/client/polyfills/css-shim/utils.ts 1 GLOBAL_SCOPE

@rwaskiewicz rwaskiewicz changed the base branch from main to v3.0.0-dev November 9, 2022 22:32
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Nov 10, 2022
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Nov 10, 2022
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810
@rwaskiewicz rwaskiewicz force-pushed the rwaskiewicz/puppeteer-upgrade branch 2 times, most recently from 61b13d3 to 3dd8ec1 Compare November 15, 2022 18:13
@rwaskiewicz rwaskiewicz marked this pull request as ready for review November 15, 2022 20:49
@rwaskiewicz rwaskiewicz requested a review from a team as a code owner November 15, 2022 20:49
Copy link
Member

@tanner-reits tanner-reits left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one small callout I wanted to verify

Comment on lines 610 to 611
puppeteer: { minVersion: '1.19.0', recommendedVersion: '19' },
'puppeteer-core': { minVersion: '1.19.0', recommendedVersion: '19' },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1.19.0 doesn't seem right so just calling out to be safe

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope - bad merge conflict resolution. Fixed in 0e4cb95

Copy link
Member

@alicewriteswrongs alicewriteswrongs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this all looks straightforward enough, I ran through the testing steps as well and confirmed that everything looks good. Just had one question about the version range.

@@ -607,8 +607,8 @@ export function createNodeSys(c: { process?: any } = {}): CompilerSystem {
'@types/jest': { minVersion: '24.9.1', recommendedVersion: '27.0.3', maxVersion: '27.0.0' },
jest: { minVersion: '24.9.1', recommendedVersion: '27.0.3', maxVersion: '27.0.0' },
'jest-cli': { minVersion: '24.9.0', recommendedVersion: '27.4.5', maxVersion: '27.0.0' },
puppeteer: { minVersion: '10.0.0', recommendedVersion: '13.5.2' },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we set a max here, like we do for jest and co?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 done in 303e7a7

this commit increments the supported version of puppeteer from v10 to
v14.

v11, v12, v13 all did not require any changes to the stencil codebase.
as a result, this commit jumps directly from v10 to v14.

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explictly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer
this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
this commit increments the suppported version of puppeteer from v15 to
v16.

v16 did not require any changes in the codebase, other than incrementing
the list of supported versions of the library.
this commit increments the supported version of puppeteer from v16 to
v17.

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

1. `ElementHandle` Scenario

in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.

the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.

in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).

2. `JSHandle` Scenario

accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.

we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
this commit increments the supported bersion of puppeteer from v17 to
v18.

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
this commit increments the supported version of pupeeteer from v18 to
v19.

there were no breaking changes in puppeteer v19 that required changes to
stencil
this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
this commit bumps the version of npm used for the karma test project to
npm v7. it also increments the version of node to v14.21. this is
required for running the latest version of puppeteer
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Nov 30, 2022
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810

this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
rwaskiewicz added a commit that referenced this pull request Dec 2, 2022
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Dec 2, 2022
feat(e2e): add support for puppteer v19 #3810
rwaskiewicz added a commit that referenced this pull request Dec 5, 2022
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Dec 5, 2022
this commit ports the documentation changes from ionic-team/stencil#3810
(ionic-team/stencil@22c7424) to the v2 version of the stencil site
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Dec 6, 2022
this commit ports the documentation changes from ionic-team/stencil#3810
(ionic-team/stencil@22c7424) to the v2 version of the stencil site
@rwaskiewicz rwaskiewicz deleted the rwaskiewicz/puppeteer-upgrade branch December 7, 2022 15:58
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Jan 20, 2023
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810

this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Jan 23, 2023
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810

this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
rwaskiewicz added a commit that referenced this pull request Jan 23, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 25, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit that referenced this pull request Jan 25, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Jan 25, 2023
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810

this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Jan 25, 2023
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810

this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Jan 25, 2023
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810

this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
rwaskiewicz added a commit to ionic-team/stencil-site that referenced this pull request Jan 25, 2023
this commit updates the support table for puppeteer versions for stencil
v3. it serves as the documentation for ionic-team/stencil#3810

this commit updates the puppeteer section of the breaking_changes
document to clarify the version of puppeteer that is supported
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants