New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: type inference for evaluation types #8547
Conversation
278f4f1
to
a00babc
Compare
db369f7
to
4b2a6c6
Compare
You could also consider changing |
@stevenwdv There are plans to handle |
6bde662
to
8df10aa
Compare
48b64af
to
b7bb1c5
Compare
9a10aec
to
72c3e42
Compare
b7bb1c5
to
5e27ac9
Compare
545a03c
to
53556a9
Compare
5e27ac9
to
f424c49
Compare
836654a
to
0c3ae52
Compare
let's document the breaking part of this PR better? let's perhaps include an example of what worked before and how it should be handled now. E.g., before |
By documenting I mean let's include an example into the PR description (and also copy everything from the PR description into the commit message when landing this). |
Ok, thanks for that. A bit confusing currently unfortunately! (mismatching types / docs). But maybe this will be remedied fairly quickly :) |
this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547.
this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547.
this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547.
this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547.
this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547.
this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547.
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
this commit adds support for puppeteer v19. it is added to the stencil v3.0.0 development branch, as puppeteer v14 no longer supports node v12, which stencil v2 still does. each section below describes the work done for each version of puppeteer. # Puppeteer v11, v12, v13 v11, v12, v13 all did not require any changes to the stencil codebase. # Puppeteer v14 the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious at the time when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary (it their early days on Stencil, and was being conservative) v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explicitly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer # Puppeteer v15 this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547. # Puppeteer v16 v16 did not require any changes in the codebase. # Puppeteer v17 puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances # Puppeteer v18 puppeteer v18 did not include any breaking changes that required major breaking changes to stencil # Puppeteer v19 puppeteer v19 did not include any breaking changes that required major breaking changes to stencil # Node, NPM versions this pr increments the versions of node & npm used to run our karma tests. the newest version of puppeteer requires use to upgrade these. consumers of stencil and puppeteer should refer to the puppeteer breaking changes guides (owned by the puppeteer team) to verify they are using the correct minimum versions of node/npm
This PR greatly improves the types within Puppeteer:
getElementByTagName
.as ...
in TypeScript to coerce the correct type (given it makes sense).waitFor
is officially gone.To migrate to these changes, there are only four things you may need to change:
ReturnType
type parameter, remove it and useas ...
andHandleFor
(if necessary).⛔
evaluate<ReturnType>(a: number, b: number) => {...}, a, b)
✅
(await evaluate(a, b) => {...}, a, b)) as ReturnType
⛔
evaluateHandle<ReturnType>(a: number, b: number) => {...}, a, b)
✅
(await evaluateHandle(a, b) => {...}, a, b)) as HandleFor<ReturnType>
⛔
evaluate(a: number, b: number) => {...}, a, b)
✅
evaluate(a, b) => {...}, a, b)
⛔
evaluate<(a: number, b: number) => void>((a, b) => {...}, a, b)
✅
evaluate(a, b) => {...}, a, b)
Fixes: #8485