Navigation Menu

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!: type inference for evaluation types #8547

Merged
merged 1 commit into from Jun 23, 2022
Merged

feat!: type inference for evaluation types #8547

merged 1 commit into from Jun 23, 2022

Conversation

jrandolf
Copy link
Contributor

@jrandolf jrandolf commented Jun 22, 2022

This PR greatly improves the types within Puppeteer:

  • Almost everything is auto-deduced.
    • Parameters don't need to be specified in the function. They are deduced from the spread.
    • Return types don't need to be specified. They are deduced from the function. (More on this below)
    • Selections based on tag names correctly deduce element type, similar to TypeScript's mechanism for getElementByTagName.
  • [BREAKING CHANGE] We've removed the ability to declare return types in type arguments for the following reasons:
    1. Setting them will indubitably break auto-deduction.
    2. You can just use as ... in TypeScript to coerce the correct type (given it makes sense).
  • [BREAKING CHANGE] waitFor is officially gone.

To migrate to these changes, there are only four things you may need to change:

  • If you set a return type using the ReturnType type parameter, remove it and use as ... and HandleFor (if necessary).
    evaluate<ReturnType>(a: number, b: number) => {...}, a, b)
    (await evaluate(a, b) => {...}, a, b)) as ReturnType
    evaluateHandle<ReturnType>(a: number, b: number) => {...}, a, b)
    (await evaluateHandle(a, b) => {...}, a, b)) as HandleFor<ReturnType>
  • If you set any type parameters in the parameters of an evaluation function, remove them.
    evaluate(a: number, b: number) => {...}, a, b)
    evaluate(a, b) => {...}, a, b)
  • If you set any type parameters in the method's declaration, remove them.
    evaluate<(a: number, b: number) => void>((a, b) => {...}, a, b)
    evaluate(a, b) => {...}, a, b)

Fixes: #8485

@stevenwdv
Copy link

You could also consider changing ElementHandle<T extends Element> to ElementHandle<T extends ParentNode> to officially support Document and ShadowRoot as well; see my PR #8540

@jrandolf
Copy link
Contributor Author

@stevenwdv There are plans to handle Nodes! Stay tuned.

@jrandolf jrandolf force-pushed the types2 branch 2 times, most recently from 6bde662 to 8df10aa Compare June 22, 2022 23:13
@jrandolf jrandolf marked this pull request as ready for review June 23, 2022 03:30
@jrandolf jrandolf changed the base branch from main to remove_type_tests June 23, 2022 06:19
@jrandolf jrandolf force-pushed the types2 branch 2 times, most recently from 9a10aec to 72c3e42 Compare June 23, 2022 06:42
@jrandolf jrandolf force-pushed the types2 branch 3 times, most recently from 545a03c to 53556a9 Compare June 23, 2022 06:52
Base automatically changed from remove_type_tests to main June 23, 2022 08:02
@jrandolf jrandolf force-pushed the types2 branch 2 times, most recently from 836654a to 0c3ae52 Compare June 23, 2022 08:06
@OrKoN
Copy link
Collaborator

OrKoN commented Jun 23, 2022

let's document the breaking part of this PR better? let's perhaps include an example of what worked before and how it should be handled now. E.g., before handle.evaluate<MyCustomType>(() => ..), after handle.evaluate(() => ..) as MyCustomType if I understood it right?

@OrKoN
Copy link
Collaborator

OrKoN commented Jun 23, 2022

By documenting I mean let's include an example into the PR description (and also copy everything from the PR description into the commit message when landing this).

@karlhorky
Copy link
Contributor

Ok, thanks for that. A bit confusing currently unfortunately! (mismatching types / docs). But maybe this will be remedied fairly quickly :)

rwaskiewicz added a commit to ionic-team/stencil that referenced this pull request Nov 9, 2022
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.
rwaskiewicz added a commit to ionic-team/stencil that referenced this pull request Nov 9, 2022
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.
rwaskiewicz added a commit to ionic-team/stencil that referenced this pull request Nov 9, 2022
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.
rwaskiewicz added a commit to ionic-team/stencil that referenced this pull request Nov 10, 2022
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.
rwaskiewicz added a commit to ionic-team/stencil that referenced this pull request Nov 15, 2022
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.
rwaskiewicz added a commit to ionic-team/stencil that referenced this pull request Nov 28, 2022
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.
rwaskiewicz added a commit to ionic-team/stencil that referenced this pull request Nov 29, 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 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 to ionic-team/stencil 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 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 to ionic-team/stencil 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 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
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.

[Types] Improve types for evaluate and evaluateHandle on various types (and JSHandle<T>)
4 participants