fix(testing): puppeteer v10 support #2934
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Remove @types/puppeteer from root package.json file - This will _not_ build at this time
- Remove @types/puppeteer - Make puppeteer@6 the minimum version (I may bump this later) - Make puppeteer@10 the recommeneded version
- Verifies the code 'builds' - really we're ensuring the type checker doesn't complain/I can run tests - I intend for the contents of this commit to be removed as I step through the various issues
- 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 - Reintroduce this as a named type here, so that it may be reused throughout Stencil-related testing files
- 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
This invocation would default to returning a Promise<Unknown>. We may return something here in theory, since an HTMLElement impl may return something concrete
Puppeteer no longer exports a type of name EmulateOptions, in favor of an object literal.
- split into two separate fields
- Make this a non-breaking change
rwaskiewicz
changed the title
- Offer better compatability between Puppeteer 5 and 10 for projects that cannot upgrade
ltm
reviewed
Jun 23, 2021
ltm
approved these changes
Jun 23, 2021
rwaskiewicz
added a commit
that referenced
this pull request
Jun 25, 2021
- 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
rwaskiewicz
added a commit
that referenced
this pull request
Jun 25, 2021
rwaskiewicz
added a commit
that referenced
this pull request
Jun 25, 2021
- 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
This was referenced Jun 25, 2021
rwaskiewicz
added a commit
that referenced
this pull request
Oct 3, 2022
- 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
rwaskiewicz
added a commit
that referenced
this pull request
Nov 9, 2022
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
rwaskiewicz
added a commit
that referenced
this pull request
Nov 10, 2022
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
rwaskiewicz
added a commit
that referenced
this pull request
Nov 15, 2022
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
14 tasks
rwaskiewicz
added a commit
that referenced
this pull request
Nov 28, 2022
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
rwaskiewicz
added a commit
that referenced
this pull request
Nov 29, 2022
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Dec 2, 2022
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Dec 5, 2022
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 23, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 24, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 25, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
rwaskiewicz
added a commit
that referenced
this pull request
Jan 25, 2023
this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.
each section below describes the work done for each version of puppeteer.
# Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
# Puppeteer v14
the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.
the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
"CommonJS"
- the `module` default causes `moduleResolution` to default to
"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
- the `target` field is set to support the private identifiers in
puppeteer
# Puppeteer v15
this commit increments the supported version of puppeteer from v14 to
v15.
starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
# Puppeteer v16
v16 did not require any changes in the codebase.
# Puppeteer v17
puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.
1. `ElementHandle` Scenario
in this scenario, an `ExecutionContext` was being pulled off an
`ElementHandle` instance.
the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
an `ElementHandle` is through the `frame` getter on the `ElementHandle`
instance. doing so does not work in puppeteer v16 and below. for those
versions of puppeteer v16 and below, stencil will default to the original
`executionContext()` behavior. otherwise, the return value of the
`frame` getter is returned from a new utility method.
in order to determine which version of puppeteer is used, a mechanism
for reading the puppeteer `package.json#version` field has been added.
this avoids clunky prototype lookups that have been used in the past,
and are not always the safest way to detect the version of puppeteer
being used (e.g. a field may exist on the prototype chain of an object
in 2 different versions of puppeteer, but do very different things).
2. `JSHandle` Scenario
accessing a `JSHandle`'s `ExecutionContext` is necessary in
`puppeteer-event.ts`. because this is the only instance where stencil
would get an `ExecutionContext` from a `JSHandle`, no utility function
for retrieving an `ExecutionContext` was created. rather, the same
effect can be achieved in a backwards compatible way by calling
`evaluate()` directly on the `JSHandle` instance.
we do not call `.asElement()` on the `JSHandle` instance and
subsequently use the "`ElementHandle` Scenario" described above as a
`JSHandle` does not always have an element associated with it, making it
impossible to get an `ExecutionContext` in such instances
# Puppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
# Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
# Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request checklist
Please check if your PR fulfills the following requirements:
npm run build) was run locallyand any changes were pushedPull request type
Please check the type of change your PR introduces:
What is the current behavior?
In this PR, we upgrade Stencil to allow support for v10.0.0 of Puppeteer. The version of Puppeteer (v5.5.0) supported in
stencil@2.6.0has two separate issues:npm installcannot be easily run in the Stencil repo itself on newer Mac machines (those using an M1). This was fixed on the Puppeteer side in feat(launcher): fix installation error on Apple M1 chips puppeteer/puppeteer#7099Issue Number: resolves #2834
What is the new behavior?
@types/puppeteerDoes this introduce a breaking change?
Manual Testing
npm buildandnpm linkfrom the root of the repo directory (on this branch)npm init stencilnpm tin my stencil app passed 👍Other information