- Update puppeteer to v10.0.0
  - Remove @types/puppeteer from root package.json file
- Update programmatic library checks
  - Remove @types/puppeteer
  - Make puppeteer@10 the recommended version
- Replace @types/puppeteer instances of PageCloseOptions
  - This interface was originally defined in v5.4.3 of the DefinitelyTyped type declaration file for Puppeteer https://github.com/DefinitelyTyped/DefinitelyTyped/blob/34edf5fb8fdf54f57ed6584f77f1611767af7f6b/types/puppeteer/index.d.ts#L1423
  - It has since been removed, and replace with an object literal of the
    same shape
https://github.com/puppeteer/puppeteer/blob/main/src/common/Page.ts#L2097
- Replace usages of NavigationOptions for WaitForOptions
  - WaitForOptions is structurally the same as @types/puppeteer's
    [NavigationOptions](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/34edf5fb8fdf54f57ed6584f77f1611767af7f6b/types/puppeteer/index.d.ts#L616)
and is used as a drop in replacement
  - The page#goTo method in Puppeteer's definition in both v5.4.3 and
    v10 allow an optional 'referer' string. Since it was omitted in the
    original implementation, I did not include it in this update
- Replace Response with HTTPResponse
- Update ElementHandle#press to use KeyInput instead of string
- Make typings of executionContext.evaluate explicit
- Migrate EmulateOptions
  - Puppeteer no longer exports a type of name EmulateOptions, in favor of
an object literal.

BREAKING CHANGE: Requires Puppeteer v10.0.0

- This commit is a backport of #2934
- Offer better compatibility between Puppeteer 5 and 10 for projects
   that cannot upgrade to newer versions of Stencil

- Update puppeteer to v10.0.0
  - Remove @types/puppeteer from root package.json file
- Update programmatic library checks
  - Remove @types/puppeteer
  - Make puppeteer@10 the recommended version
- Replace @types/puppeteer instances of PageCloseOptions
  - This interface was originally defined in v5.4.3 of the DefinitelyTyped type declaration file for Puppeteer https://github.com/DefinitelyTyped/DefinitelyTyped/blob/34edf5fb8fdf54f57ed6584f77f1611767af7f6b/types/puppeteer/index.d.ts#L1423
  - It has since been removed, and replace with an object literal of the
    same shape
https://github.com/puppeteer/puppeteer/blob/main/src/common/Page.ts#L2097
- Replace usages of NavigationOptions for WaitForOptions
  - WaitForOptions is structurally the same as @types/puppeteer's
    [NavigationOptions](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/34edf5fb8fdf54f57ed6584f77f1611767af7f6b/types/puppeteer/index.d.ts#L616)
and is used as a drop in replacement
  - The page#goTo method in Puppeteer's definition in both v5.4.3 and
    v10 allow an optional 'referer' string. Since it was omitted in the
    original implementation, I did not include it in this update
- Replace Response with HTTPResponse
- Update ElementHandle#press to use KeyInput instead of string
- Make typings of executionContext.evaluate explicit
- Migrate EmulateOptions
  - Puppeteer no longer exports a type of name EmulateOptions, in favor of
an object literal.

BREAKING CHANGE: Requires Puppeteer v10.0.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

this commit 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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