-
Notifications
You must be signed in to change notification settings - Fork 789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(e2e): add support for puppteer v19 #3810
Conversation
|
Path | Error Count |
---|---|
src/compiler/config/test/validate-dev-server.spec.ts | 45 |
src/compiler/config/test/validate-output-www.spec.ts | 40 |
src/screenshot/connector-base.ts | 40 |
src/dev-server/index.ts | 38 |
src/mock-doc/serialize-node.ts | 36 |
src/compiler/sys/tests/in-memory-fs.spec.ts | 34 |
src/screenshot/screenshot-compare.ts | 33 |
src/compiler/transformers/test/parse-props.spec.ts | 32 |
src/dev-server/server-process.ts | 32 |
src/runtime/vdom/vdom-render.ts | 31 |
src/compiler/sys/typescript/typescript-config.ts | 28 |
src/compiler/build/build-stats.ts | 27 |
src/compiler/output-targets/dist-lazy/generate-lazy-module.ts | 26 |
src/compiler/prerender/prerender-main.ts | 25 |
src/sys/node/test/worker-manager.spec.ts | 24 |
src/compiler/style/test/optimize-css.spec.ts | 23 |
src/compiler/sys/in-memory-fs.ts | 23 |
src/runtime/update-component.ts | 23 |
src/testing/puppeteer/puppeteer-element.ts | 23 |
src/compiler/config/test/validate-paths.spec.ts | 22 |
Our most common errors
Typescript Error Code | Count | Error messages |
---|---|---|
TS2532 | 647 | Error messagesObject is possibly 'undefined'. |
TS2345 | 609 | Error messagesArgument of type 'CompilerSystem | undefined' is not assignable to parameter of type 'CompilerSystem'.Type 'undefined' is not assignable to type 'CompilerSystem'. Argument of type 'string | undefined' is not assignable to parameter of type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type 'Promise<(() => void) | null>' is not assignable to parameter of type 'Promise<() => void>'. Argument of type 'null' is not assignable to parameter of type 'BuildResultsComponentGraph'. Argument of type 'DevServerConfig | undefined' is not assignable to parameter of type 'StencilDevServerConfig'. Type 'undefined' is not assignable to type 'StencilDevServerConfig'. Argument of type 'Promise<(() => void) | null>' is not assignable to parameter of type 'Promise<() => void>'. Type '(() => void) | null' is not assignable to type '() => void'. Type 'null' is not assignable to type '() => void'. Argument of type 'ComponentRuntimeHostListener[] | undefined' is not assignable to parameter of type 'ComponentRuntimeHostListener[]'. Type 'undefined' is not assignable to type 'ComponentRuntimeHostListener[]'. Argument of type 'HTMLScriptElement | null | undefined' is not assignable to parameter of type 'HTMLScriptElement'. Type 'undefined' is not assignable to type 'HTMLScriptElement'. Argument of type 'string | null' is not assignable to parameter of type 'string'. Type 'null' is not assignable to type 'string'. Argument of type 'Logger | undefined' is not assignable to parameter of type 'Logger'. Type 'undefined' is not assignable to type 'Logger'. Argument of type 'string[] | undefined' is not assignable to parameter of type 'string[]'. Type 'undefined' is not assignable to type 'string[]'. Argument of type 'string' is not assignable to parameter of type 'never'. Argument of type 'Diagnostic[] | undefined' is not assignable to parameter of type 'readonly Diagnostic[]'. Type 'undefined' is not assignable to type 'readonly Diagnostic[]'. Argument of type 'boolean | undefined' is not assignable to parameter of type 'boolean'. Argument of type 'BuildConditionals | undefined' is not assignable to parameter of type 'BuildConditionals'. Type 'undefined' is not assignable to type 'BuildConditionals'. Argument of type 'Diagnostic[] | undefined' is not assignable to parameter of type 'Diagnostic[]'. Type 'undefined' is not assignable to type 'Diagnostic[]'. Argument of type 'WorkerMeta | undefined' is not assignable to parameter of type 'WorkerMeta'. Type 'undefined' is not assignable to type 'WorkerMeta'. Argument of type 'string | null | undefined' is not assignable to parameter of type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type 'Set<string | null>' is not assignable to parameter of type 'Set'. Type 'string | null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'. Argument of type 'Set<string | null>' is not assignable to parameter of type 'Set'. Argument of type 'RollupConfig | undefined' is not assignable to parameter of type 'RollupConfig'. Type 'undefined' is not assignable to type 'RollupConfig'. Argument of type '(string[] | undefined)[]' is not assignable to parameter of type 'string[][]'. Type 'string[] | undefined' is not assignable to type 'string[]'. Type 'undefined' is not assignable to type 'string[]'. Argument of type 'ComponentCompilerMeta | undefined' is not assignable to parameter of type 'ComponentCompilerMeta'. Type 'undefined' is not assignable to type 'ComponentCompilerMeta'. Argument of type 'true | Object | undefined' is not assignable to parameter of type 'boolean | Object | null'. Type 'undefined' is not assignable to type 'boolean | Object | null'. Argument of type 'SourceTarget | undefined' is not assignable to parameter of type 'SourceTarget'. Type 'undefined' is not assignable to type 'SourceTarget'. Argument of type 'boolean | undefined' is not assignable to parameter of type 'boolean'. Type 'undefined' is not assignable to type 'boolean'. Argument of type '(string | undefined)[]' is not assignable to parameter of type 'string[]'. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type '(string | undefined)[]' is not assignable to parameter of type 'string[]'. Argument of type 'RollupSourceMap | undefined' is not assignable to parameter of type 'SourceMap'. Type 'undefined' is not assignable to type 'SourceMap'. Argument of type 'EntryModule | undefined' is not assignable to parameter of type 'EntryModule'. Type 'undefined' is not assignable to type 'EntryModule'. Argument of type '(Module | undefined)[]' is not assignable to parameter of type 'Module[]'. Type 'Module | undefined' is not assignable to type 'Module'. Type 'undefined' is not assignable to type 'Module'. Argument of type 'Document | null' is not assignable to parameter of type 'Document'. Type 'null' is not assignable to type 'Document'. Argument of type 'Document | null' is not assignable to parameter of type 'Node | MockNode'. Type 'null' is not assignable to type 'Node | MockNode'. Argument of type 'HydrateAnchorElement' is not assignable to parameter of type '{ [attrName: string]: string; }'. 'string' index signatures are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type 'URL | null' is not assignable to parameter of type 'URL'. Type 'null' is not assignable to type 'URL'. Argument of type 'number | undefined' is not assignable to parameter of type 'number'. Type 'undefined' is not assignable to type 'number'. Argument of type 'SitemapXmpResults | null' is not assignable to parameter of type 'SitemapXmpResults'. Type 'null' is not assignable to type 'SitemapXmpResults'. Argument of type 'string | undefined' is not assignable to parameter of type 'string | URL'. Argument of type 'Map<string, string[]> | undefined' is not assignable to parameter of type 'Map<string, string[]>'. Type 'undefined' is not assignable to type 'Map<string, string[]>'. Argument of type 'undefined' is not assignable to parameter of type 'string'. Argument of type 'ServiceWorkerConfig | undefined' is not assignable to parameter of type 'ServiceWorkerConfig'. Type 'undefined' is not assignable to type 'ServiceWorkerConfig'. Argument of type 'string | undefined' is not assignable to parameter of type 'string | URL'. Type 'undefined' is not assignable to type 'string | URL'. Argument of type 'CssNode[] | null | undefined' is not assignable to parameter of type 'void | CssNode[]'. Argument of type 'CssNode[] | null | undefined' is not assignable to parameter of type 'void | CssNode[]'. Type 'null' is not assignable to type 'void | CssNode[]'. Argument of type 'null' is not assignable to parameter of type 'string'. Argument of type 'CompilerSystemCreateDirectoryOptions | undefined' is not assignable to parameter of type 'CompilerSystemCreateDirectoryOptions'. Type 'undefined' is not assignable to type 'CompilerSystemCreateDirectoryOptions'. Argument of type 'null' is not assignable to parameter of type 'CompilerFileWatcherEvent'. Argument of type 'null' is not assignable to parameter of type '{ access: (filePath: string) => Promise; accessSync: (filePath: string) => boolean; cancelDeleteDirectoriesFromDisk: (dirPaths: string[]) => void; cancelDeleteFilesFromDisk: (filePaths: string[]) => void; ... 17 more ...; writeFiles: (files: { ...; } | Map<...>, opts?: FsWriteOptions | undefined) => Promise...'. Argument of type 'undefined' is not assignable to parameter of type 'TypeChecker'. Argument of type 'CollectionBundleManifest[] | undefined' is not assignable to parameter of type 'any[]'. Type 'undefined' is not assignable to type 'any[]'. Argument of type 'Module | undefined' is not assignable to parameter of type 'Module'. Type 'undefined' is not assignable to type 'Module'. Argument of type 'NodeArray | undefined' is not assignable to parameter of type 'NodeArray | HeritageClause[]'. Type 'undefined' is not assignable to type 'NodeArray | HeritageClause[]'. Argument of type 'Block | undefined' is not assignable to parameter of type 'Block'. Type 'undefined' is not assignable to type 'Block'. Argument of type 'undefined' is not assignable to parameter of type 'readonly ParameterDeclaration[]'. Argument of type 'Expression | undefined' is not assignable to parameter of type 'Expression'. Type 'undefined' is not assignable to type 'Expression'. Argument of type 'Symbol | undefined' is not assignable to parameter of type 'Symbol'. Type 'undefined' is not assignable to type 'Symbol'. Argument of type 'TypeNode | undefined' is not assignable to parameter of type 'Node'. Type 'undefined' is not assignable to type 'Node'. Argument of type '(PropertyAssignment | null)[]' is not assignable to parameter of type 'readonly ObjectLiteralElementLike[]'. Type 'PropertyAssignment | null' is not assignable to type 'ObjectLiteralElementLike'. Type 'null' is not assignable to type 'ObjectLiteralElementLike'. Argument of type 'Signature | undefined' is not assignable to parameter of type 'Signature'. Type 'undefined' is not assignable to type 'Signature'. Argument of type '(PropertyAssignment | null)[]' is not assignable to parameter of type 'readonly ObjectLiteralElementLike[]'. Argument of type 'Identifier | undefined' is not assignable to parameter of type 'Node'. Type 'undefined' is not assignable to type 'Node'. Argument of type 'undefined' is not assignable to parameter of type 'readonly ClassElement[]'. Argument of type 'Config | null | undefined' is not assignable to parameter of type 'Config'. Type 'undefined' is not assignable to type 'Config'. Argument of type 'null' is not assignable to parameter of type 'CollectionCompilerMeta'. Argument of type 'PropertyName | undefined' is not assignable to parameter of type 'PropertyName'. Type 'undefined' is not assignable to type 'PropertyName'. Argument of type 'NamedExportBindings | undefined' is not assignable to parameter of type 'Node'. Type 'undefined' is not assignable to type 'Node'. Argument of type 'Declaration | undefined' is not assignable to parameter of type 'Node'. Type 'undefined' is not assignable to type 'Node'. Argument of type 'Identifier | undefined' is not assignable to parameter of type 'string | BindingName'. Type 'undefined' is not assignable to type 'string | BindingName'. Argument of type 'ScriptTarget | undefined' is not assignable to parameter of type 'ScriptTarget | CreateSourceFileOptions'. Type 'undefined' is not assignable to type 'ScriptTarget | CreateSourceFileOptions'. Argument of type 'Diagnostic' is not assignable to parameter of type 'DiagnosticWithLocation'. Types of property 'file' are incompatible. Type 'SourceFile | undefined' is not assignable to type 'SourceFile'. Type 'undefined' is not assignable to type 'SourceFile'. Argument of type '(...pathSegments: string[]) => string | undefined' is not assignable to parameter of type '(...args: string[]) => string'. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type 'OpenInEditorCallback | undefined' is not assignable to parameter of type 'OpenInEditorCallback'. Type 'undefined' is not assignable to type 'OpenInEditorCallback'. Argument of type 'CompilerWatcher | undefined' is not assignable to parameter of type 'CompilerWatcher'. Type 'undefined' is not assignable to type 'CompilerWatcher'. Argument of type '{ editor: string | undefined; }' is not assignable to parameter of type 'OpenInEditorOptions'. Types of property 'editor' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type 'string | undefined' is not assignable to parameter of type 'PathLike'. Argument of type 'DevServerConfig | undefined' is not assignable to parameter of type 'DevServerConfig'. Type 'undefined' is not assignable to type 'DevServerConfig'. Argument of type 'CompilerBuildResults | undefined' is not assignable to parameter of type 'CompilerBuildResults'. Type 'undefined' is not assignable to type 'CompilerBuildResults'. Argument of type 'Window | undefined' is not assignable to parameter of type 'Window'. Type 'undefined' is not assignable to type 'Window'. Argument of type 'SerializeDocumentOptions | undefined' is not assignable to parameter of type 'HydrateDocumentOptions'. Type 'undefined' is not assignable to type 'HydrateDocumentOptions'. Argument of type 'HydrateDocumentOptions | undefined' is not assignable to parameter of type 'HydrateDocumentOptions'. Type 'undefined' is not assignable to type 'HydrateDocumentOptions'. Argument of type 'MockNode | null' is not assignable to parameter of type 'MockNode'. Type 'null' is not assignable to type 'MockNode'. Argument of type 'string | undefined' is not assignable to parameter of type 'string | null'. Type 'undefined' is not assignable to type 'string | null'. Argument of type 'string | undefined' is not assignable to parameter of type 'string | null'. Argument of type 'ShadowRoot | null' is not assignable to parameter of type 'Node'. Type 'null' is not assignable to type 'Node'. Argument of type 'MockElement' is not assignable to parameter of type 'MockHTMLElement'. Types of property 'namespaceURI' are incompatible. Type 'string | null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'. Argument of type 'null' is not assignable to parameter of type 'string | Node'. Argument of type 'null' is not assignable to parameter of type 'string | boolean | undefined'. Argument of type '(Window & typeof globalThis) | null' is not assignable to parameter of type 'Window'. Type 'null' is not assignable to type 'Window'. Argument of type 'string | null | undefined' is not assignable to parameter of type 'string | undefined'. Argument of type 'HostRef | undefined' is not assignable to parameter of type 'HostRef'. Type 'undefined' is not assignable to type 'HostRef'. Argument of type 'this' is not assignable to parameter of type 'HostElement'. Type 'HostElement' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/declarations/stencil-private").HostElement'. The types returned by 'componentOnReady()' are incompatible between these types. Type 'Promise | undefined' is not assignable to type 'Promise'. Type 'undefined' is not assignable to type 'Promise'. Argument of type 'this' is not assignable to parameter of type 'HostElement'. Argument of type 'string | null' is not assignable to parameter of type 'string | undefined'. Argument of type 'PropertyDescriptor | undefined' is not assignable to parameter of type 'PropertyDescriptor & ThisType'. Type 'undefined' is not assignable to type 'PropertyDescriptor & ThisType'. Type 'undefined' is not assignable to type 'PropertyDescriptor'. Argument of type 'HTMLElement | undefined' is not assignable to parameter of type 'HTMLElement'. Type 'undefined' is not assignable to type 'HTMLElement'. Argument of type 'HostElement | undefined' is not assignable to parameter of type 'HostElement'. Type 'undefined' is not assignable to type 'HostElement'. Argument of type 'HostElement | undefined' is not assignable to parameter of type 'EventTarget'. Type 'undefined' is not assignable to type 'EventTarget'. Argument of type 'HostElement | undefined' is not assignable to parameter of type 'Element'. Type 'undefined' is not assignable to type 'Element'. Argument of type 'VNode[] | undefined' is not assignable to parameter of type 'VNode[]'. Type 'undefined' is not assignable to type 'VNode[]'. Argument of type 'null | undefined' is not assignable to parameter of type 'ChildType'. Type 'undefined' is not assignable to type 'ChildType'. Argument of type 'VNode | null' is not assignable to parameter of type 'ChildType'. Type 'null' is not assignable to type 'ChildType'. Argument of type 'VNode | undefined' is not assignable to parameter of type 'ChildType'. Type 'undefined' is not assignable to type 'ChildType'. Argument of type 'VNode | null | undefined' is not assignable to parameter of type 'ChildType'. Type 'undefined' is not assignable to type 'ChildType'. Argument of type 'null | undefined' is not assignable to parameter of type 'ChildType'. Argument of type 'RenderNode | undefined' is not assignable to parameter of type 'Node | null'. Type 'undefined' is not assignable to type 'Node | null'. Argument of type 'VNode | undefined' is not assignable to parameter of type 'VNode'. Type 'undefined' is not assignable to type 'VNode'. Argument of type 'null' is not assignable to parameter of type 'VNode'. Argument of type 'RenderNode | undefined' is not assignable to parameter of type 'Node'. Type 'undefined' is not assignable to type 'Node'. Argument of type 'null' is not assignable to parameter of type 'RenderNode'. Argument of type 'ScreenshotDiff | undefined' is not assignable to parameter of type 'ScreenshotDiff'. Type 'undefined' is not assignable to type 'ScreenshotDiff'. Argument of type 'string | undefined' is not assignable to parameter of type 'PathLike'. Type 'undefined' is not assignable to type 'PathLike'. Argument of type 'string | undefined' is not assignable to parameter of type 'string | SemVer'. Type 'undefined' is not assignable to type 'string | SemVer'. Argument of type 'string | undefined' is not assignable to parameter of type 'string | SemVer'. Argument of type 'null' is not assignable to parameter of type 'number | undefined'. Argument of type 'null' is not assignable to parameter of type 'number | PromiseLike'. Argument of type 'CompilerWorkerTask | undefined' is not assignable to parameter of type 'CompilerWorkerTask'. Type 'undefined' is not assignable to type 'CompilerWorkerTask'. Argument of type 'null' is not assignable to parameter of type 'CompilerWorkerTask'. Argument of type 'undefined' is not assignable to parameter of type 'ErrorHandler'. Argument of type 'string | undefined' is not assignable to parameter of type 'MockRequestInfo'. Type 'undefined' is not assignable to type 'MockRequestInfo'. Argument of type 'string | undefined' is not assignable to parameter of type 'MockRequestInfo'. Argument of type 'MockResponse | undefined' is not assignable to parameter of type 'MockResponse'. Type 'undefined' is not assignable to type 'MockResponse'. Argument of type 'RuntimeRef | undefined' is not assignable to parameter of type 'RuntimeRef'. Type 'undefined' is not assignable to type 'RuntimeRef'. Argument of type 'this' is not assignable to parameter of type 'E2EElementInternal'. Type 'E2EElement' is not assignable to type 'E2EElementInternal'. Types of property 'find' are incompatible. Type '(selector: string) => Promise<E2EElement | null>' is not assignable to type '(selector: FindSelector) => Promise'. Argument of type '(elm: Element, pseudoElt: string) => any' is not assignable to parameter of type 'string | EvaluateFunc<[ElementHandle, string | null | undefined]>'. Type '(elm: Element, pseudoElt: string) => any' is not assignable to type 'EvaluateFunc<[ElementHandle, string | null | undefined]>'. Types of parameters 'pseudoElt' and 'params_1' are incompatible. Type 'string | null | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type 'this' is not assignable to parameter of type 'E2EElementInternal'. Argument of type '{ viewport: EmulateViewport | undefined; userAgent: string | undefined; }' is not assignable to parameter of type 'Device'. Types of property 'userAgent' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Argument of type 'null' is not assignable to parameter of type 'SourceMap | undefined'. |
TS2322 | 527 | Error messagesType 'string | null | undefined' is not assignable to type 'string'.Type 'undefined' is not assignable to type 'string'. Type 'null' is not assignable to type 'DevServerConfig | undefined'. Type 'boolean | null | undefined' is not assignable to type 'boolean | undefined'. Type 'null' is not assignable to type 'boolean | undefined'. Type 'null' is not assignable to type 'DevServer'. Type 'undefined' is not assignable to type 'ComponentConstructor | Promise'. Type 'HTMLElement | null' is not assignable to type 'HTMLElement'. Type 'null' is not assignable to type 'HTMLElement'. Type '({ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; } | { ...; })[]' is not assignable to type 'RollupResult[]'. Type '{ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; } | { ...; }' is not assignable to type 'RollupResult'. Type '{ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; }' is not assignable to type 'RollupResult'. Type '{ type: "chunk"; fileName: string; map: SourceMap | undefined; code: string; moduleFormat: ModuleFormat | undefined; entryKey: string; imports: string[]; isEntry: boolean; ... 4 more ...; content?: undefined; }' is not assignable to type 'RollupChunkResult'. Types of property 'moduleFormat' are incompatible. Type 'ModuleFormat | undefined' is not assignable to type 'ModuleFormat'. Type 'undefined' is not assignable to type 'ModuleFormat'. Type 'null' is not assignable to type 'CompilerBuildResults'. Type 'undefined' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'Document'. Type 'null' is not assignable to type 'Promise'. Type 'null' is not assignable to type 'LoggerTimeSpan'. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type 'boolean | undefined' is not assignable to type 'boolean'. Type 'number | undefined' is not assignable to type 'number'. Type 'undefined' is not assignable to type 'number'. Type 'boolean | "prod" | undefined' is not assignable to type 'boolean | "prod"'. Type 'undefined' is not assignable to type 'boolean | "prod"'. Type 'BuildResultsComponentGraph | undefined' is not assignable to type 'BuildResultsComponentGraph'. Type 'undefined' is not assignable to type 'BuildResultsComponentGraph'. Type 'RollupResults | undefined' is not assignable to type 'RollupResults'. Type 'undefined' is not assignable to type 'RollupResults'. Type '{ name: string | undefined; source: string; tags: any[]; }[]' is not assignable to type '{ name: string; source: string; tags: string[]; }[]'. Type '{ name: string | undefined; source: string; tags: any[]; }' is not assignable to type '{ name: string; source: string; tags: string[]; }'. Types of property 'name' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type 'null' is not assignable to type 'CompilerWorkerContext'. Type 'null' is not assignable to type 'WatchOfConfigFile'. Type 'null' is not assignable to type 'Promise<(void | void[])[]>'. Type 'Promise<(void | void[] | null)[]>' is not assignable to type 'Promise<(void | void[])[]>'. Type '(void | void[] | null)[]' is not assignable to type '(void | void[])[]'. Type 'void | void[] | null' is not assignable to type 'void | void[]'. Type 'null' is not assignable to type 'void | void[]'. Type 'null' is not assignable to type '{ program: WatchOfConfigFile; rebuild: () => void; }'. Type '(this: PluginContext, importee: string, importer: string) => Promise' is not assignable to type 'ResolveIdHook'. Types of parameters 'importer' and 'importer' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type '(this: PluginContext, importee: string, importer: string) => Promise' is not assignable to type 'ResolveIdHook'. Types of parameters 'importer' and 'importer' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type 'string | null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string | undefined'. Type 'string' is not assignable to type 'never'. Type 'null' is not assignable to type 'never'. Type 'never[]' is not assignable to type 'never'. Type '{ code: string; exports: string[]; workerMsgId: string; dependencies: string[]; } | null' is not assignable to type 'WorkerMeta | undefined'. Type 'null' is not assignable to type 'WorkerMeta | undefined'. Type 'WorkerMeta | undefined' is not assignable to type 'WorkerMeta'. Type 'undefined' is not assignable to type 'WorkerMeta'. Type 'CompilerSystem | undefined' is not assignable to type 'CompilerSystem'. Type 'undefined' is not assignable to type 'CompilerSystem'. Type 'Logger | undefined' is not assignable to type 'Logger'. Type 'undefined' is not assignable to type 'Logger'. Type 'import("/home/runner/work/stencil/stencil/src/compiler/cache").Cache' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/declarations/stencil-private").Cache'. The types returned by 'get(...)' are incompatible between these types. Type 'Promise<string | null>' is not assignable to type 'Promise'. Type 'null' is not assignable to type 'ValidatedConfig'. Type 'null' is not assignable to type 'Config'. Type 'null' is not assignable to type 'string[]'. Type '{ dir: string; buildDir: string; collectionDir: string | null; typesDir: string; esmLoaderPath: string; copy: d.CopyTask[]; polyfills: boolean | undefined; empty: boolean; transformAliasedImportPathsInCollection: boolean; type: "dist"; }' is not assignable to type 'Required'. Types of property 'polyfills' are incompatible. Type 'boolean | undefined' is not assignable to type 'boolean'. Type 'null' is not assignable to type 'number | undefined'. Type 'null' is not assignable to type 'HistoryApiFallback | undefined'. Type 'null' is not assignable to type 'CopyTask[] | undefined'. Type '{ dirPath: string; filePath: string; fileName: string; readmePath: string; usagesDir: string; tag: string; readme: string | undefined; overview: string; usage: JsonDocsUsage; ... 13 more ...; listeners: JsonDocsListener[]; }[]' is not assignable to type 'JsonDocsComponent[]'. Type '{ dirPath: string; filePath: string; fileName: string; readmePath: string; usagesDir: string; tag: string; readme: string | undefined; overview: string; usage: d.JsonDocsUsage; docs: string; ... 12 more ...; listeners: d.JsonDocsListener[]; }' is not assignable to type 'JsonDocsComponent'. Types of property 'readme' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type 'string[] | undefined' is not assignable to type 'string[]'. Type 'undefined' is not assignable to type 'string[]'. Type '{ name: string; type: string; mutable: boolean; attr: string | undefined; reflectToAttr: boolean; docs: string; docsTags: CompilerJsDocTagInfo[]; default: string | undefined; deprecation: string | undefined; values: JsonDocsValue[]; optional: boolean; required: boolean; }[]' is not assignable to type 'JsonDocsProp[]'. Type '{ name: string; type: string; mutable: boolean; attr: string | undefined; reflectToAttr: boolean; docs: string; docsTags: d.CompilerJsDocTagInfo[]; default: string | undefined; deprecation: string | undefined; values: d.JsonDocsValue[]; optional: boolean; required: boolean; }' is not assignable to type 'JsonDocsProp'. Types of property 'default' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type '{ name: string; type: string; mutable: false; attr: string; reflectToAttr: false; docs: string; docsTags: never[]; default: undefined; deprecation: undefined; values: JsonDocsValue[]; optional: true; required: false; }[]' is not assignable to type 'JsonDocsProp[]'. Type '{ name: string; type: string; mutable: false; attr: string; reflectToAttr: false; docs: string; docsTags: never[]; default: undefined; deprecation: undefined; values: d.JsonDocsValue[]; optional: true; required: false; }' is not assignable to type 'JsonDocsProp'. Types of property 'default' are incompatible. Type 'undefined' is not assignable to type 'string'. Type '(ComponentCompilerMeta | undefined)[]' is not assignable to type 'ComponentCompilerMeta[]'. Type 'ComponentCompilerMeta | undefined' is not assignable to type 'ComponentCompilerMeta'. Type 'undefined' is not assignable to type 'ComponentCompilerMeta'. Type '(ComponentCompilerMeta | undefined)[][]' is not assignable to type 'readonly ComponentCompilerMeta[][]'. Type '(ComponentCompilerMeta | undefined)[]' is not assignable to type 'ComponentCompilerMeta[]'. Type 'null' is not assignable to type 'boolean | SourceMapOptions | undefined'. Type 'null' is not assignable to type 'SourceMap | undefined'. Type '{ name: string | undefined; tags: string[]; }[]' is not assignable to type 'CollectionDependencyData[]'. Type '{ name: string | undefined; tags: string[]; }' is not assignable to type 'CollectionDependencyData'. Types of property 'name' are incompatible. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type 'string | undefined' is not assignable to type 'string | number'. Type 'undefined' is not assignable to type 'string | number'. Type 'SourceMap | undefined' is not assignable to type 'SourceMap'. Type 'undefined' is not assignable to type 'SourceMap'. Type 'string | null' is not assignable to type 'string | undefined'. Type 'null' is not assignable to type 'string | undefined'. Type 'null' is not assignable to type 'Function'. Type 'null' is not assignable to type 'Map<string, string[]>'. Type 'null' is not assignable to type 'PrerenderConfig'. Type 'null' is not assignable to type 'Set'. Type 'null' is not assignable to type 'HydrateAnchorElement[]'. Type 'null' is not assignable to type '(prerenderRequest: PrerenderUrlRequest) => Promise'. Type 'CssNode | null' is not assignable to type 'void | CssNode'. Type 'null' is not assignable to type 'void | CssNode'. Type 'CssNode | null' is not assignable to type 'CssNode'. Type 'null' is not assignable to type 'CssNode'. Type 'CssNode | null' is not assignable to type 'void | CssNode'. Type 'RegExpExecArray | null' is not assignable to type 'RegExpExecArray'. Type 'null' is not assignable to type 'RegExpExecArray'. Type 'null' is not assignable to type '() => string'. Type 'null' is not assignable to type 'number'. Type 'null' is not assignable to type 'boolean'. Type 'null' is not assignable to type 'boolean | undefined'. Type 'FsItem | undefined' is not assignable to type 'FsItem'. Type 'undefined' is not assignable to type 'FsItem'. Type 'null' is not assignable to type 'CompilerFileWatcherCallback[]'. Type '(key: string) => string | undefined' is not assignable to type '(key: string) => string'. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type '(p: string) => Promise<string | undefined>' is not assignable to type '{ (p: string): Promise; (p: string, encoding: "utf8"): Promise; (p: string, encoding: "binary"): Promise; }'. Type 'Promise<string | undefined>' is not assignable to type 'Promise'. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type '(p: string) => string | undefined' is not assignable to type '(p: string, encoding?: string | undefined) => string'. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type '((maxConcurrentWorkers: number) => WorkerMainController) | null' is not assignable to type '((maxConcurrentWorkers: number) => WorkerMainController) | undefined'. Type 'null' is not assignable to type '((maxConcurrentWorkers: number) => WorkerMainController) | undefined'. Type 'null' is not assignable to type 'ResolvedModuleWithFailedLookupLocations'. Type 'null' is not assignable to type 'Worker'. Type 'CollectionCompilerMeta | undefined' is not assignable to type 'CollectionCompilerMeta'. Type 'undefined' is not assignable to type 'CollectionCompilerMeta'. Type 'DeclarationName | undefined' is not assignable to type 'DeclarationName'. Type 'undefined' is not assignable to type 'DeclarationName'. Type 'null' is not assignable to type 'PropertyAssignment'. Type 'boolean | null' is not assignable to type 'boolean'. Type 'null' is not assignable to type 'boolean'. Type 'undefined' is not assignable to type 'ComponentCompilerVirtualProperty'. Type '{ name: string; method: string; bubbles: boolean; cancelable: boolean; composed: boolean; docs: CompilerJsDoc; complexType: ComponentCompilerEventComplexType; internal: boolean | undefined; }[]' is not assignable to type 'ComponentCompilerEvent[]'. Type '{ name: string; method: string; bubbles: boolean; cancelable: boolean; composed: boolean; docs: d.CompilerJsDoc; complexType: d.ComponentCompilerEventComplexType; internal: boolean | undefined; }' is not assignable to type 'ComponentCompilerEvent'. Types of property 'internal' are incompatible. Type 'boolean | undefined' is not assignable to type 'boolean'. Type '{ name: string; docs: CompilerJsDoc; complexType: ComponentCompilerMethodComplexType; internal: boolean | undefined; }[]' is not assignable to type 'ComponentCompilerMethod[]'. Type '{ name: string; docs: d.CompilerJsDoc; complexType: d.ComponentCompilerMethodComplexType; internal: boolean | undefined; }' is not assignable to type 'ComponentCompilerMethod'. Types of property 'internal' are incompatible. Type 'boolean | undefined' is not assignable to type 'boolean'. Type '{ name: string; type: ComponentCompilerPropertyType; attribute: string | undefined; reflect: boolean; mutable: boolean; required: boolean; optional: boolean; defaultValue: string | undefined; complexType: ComponentCompilerPropertyComplexType; docs: CompilerJsDoc; internal: boolean | undefined; }[]' is not assignable to type 'ComponentCompilerProperty[]'. Type '{ name: string; type: d.ComponentCompilerPropertyType; attribute: string | undefined; reflect: boolean; mutable: boolean; required: boolean; optional: boolean; defaultValue: string | undefined; complexType: d.ComponentCompilerPropertyComplexType; docs: d.CompilerJsDoc; internal: boolean | undefined; }' is not assignable to type 'ComponentCompilerProperty'. Types of property 'internal' are incompatible. Type 'boolean | undefined' is not assignable to type 'boolean'. Type 'null' is not assignable to type 'ImportData'. Type 'undefined' is not assignable to type '"queryparams" | null'. Type 'null' is not assignable to type 'WeakSet'. Type 'null' is not assignable to type 'Module'. Type 'Module | undefined' is not assignable to type 'Module'. Type 'undefined' is not assignable to type 'Module'. Type 'undefined' is not assignable to type 'CompilerJsDoc'. Type '{ [x: string]: d.TypesMemberNameData[] | undefined; }' is not assignable to type 'TypesImportData'. 'string' index signatures are incompatible. Type 'TypesMemberNameData[] | undefined' is not assignable to type 'TypesMemberNameData[]'. Type 'undefined' is not assignable to type 'TypesMemberNameData[]'. Type 'string | undefined' is not assignable to type 'string | null'. Type '((data: { file: string; line: number; column: number; }) => void) | null' is not assignable to type 'OpenInEditorCallback | undefined'. Type 'null' is not assignable to type 'OpenInEditorCallback | undefined'. Type 'null' is not assignable to type 'WebSocket'. Type 'null' is not assignable to type 'BuildOnEventRemove'. Type 'null' is not assignable to type '() => void'. Type 'null' is not assignable to type '(msg: DevServerMessage) => void'. Type 'DevServerConfig | undefined' is not assignable to type 'DevServerConfig'. Type 'undefined' is not assignable to type 'DevServerConfig'. Type 'null' is not assignable to type '{ open(openId: string): Promise; }'. Type 'string | null' is not assignable to type 'string | undefined'. Type 'null' is not assignable to type 'Promise<DevServerEditor[]>'. Type 'null' is not assignable to type '(req: IncomingMessage, res: ServerResponse, next: () => void) => void'. Type 'null' is not assignable to type 'URL'. Type 'null' is not assignable to type 'URLSearchParams'. Type 'PageReloadStrategy | undefined' is not assignable to type 'PageReloadStrategy'. Type 'undefined' is not assignable to type 'PageReloadStrategy'. Type 'null' is not assignable to type 'Server<typeof IncomingMessage, typeof ServerResponse>'. Type 'null' is not assignable to type 'DevWebSocket'. Type 'null' is not assignable to type 'DevServerContext'. Type 'DevWebSocket | null' is not assignable to type 'DevWebSocket'. Type 'null' is not assignable to type 'DevWebSocket'. Type 'null' is not assignable to type 'ChildProcess'. Type 'null' is not assignable to type 'HydrateApp'. Type '() => undefined' is not assignable to type '{ (cb?: (() => void) | undefined): TestServerResponse; (chunk: any, cb?: (() => void) | undefined): TestServerResponse; (chunk: any, encoding: BufferEncoding, cb?: (() => void) | undefined): TestServerResponse; }'. Type 'undefined' is not assignable to type 'TestServerResponse'. Type 'null' is not assignable to type 'ComponentConstructor'. Type '(this: HostElement) => Promise | undefined' is not assignable to type '() => Promise'. Type 'Promise | undefined' is not assignable to type 'Promise'. Type 'undefined' is not assignable to type 'Promise'. Type 'null' is not assignable to type 'Window & typeof globalThis'. Type 'null' is not assignable to type 'Window'. Type 'null' is not assignable to type 'Window & typeof globalThis'. Type 'null' is not assignable to type 'MockCSSStyleSheet'. Type 'null' is not assignable to type 'string | boolean'. Type 'null' is not assignable to type 'Location'. Type 'null' is not assignable to type 'MockElement'. Type 'null' is not assignable to type 'SVGSVGElement'. Type 'null' is not assignable to type 'SVGElement'. Type 'null' is not assignable to type 'EventTarget'. Type 'null' is not assignable to type 'MockEventListener[]'. Type 'null' is not assignable to type 'MockDocument'. Type '{ name: string; value: string; namespace: string | null; prefix: null; }[]' is not assignable to type 'Attribute[]'. Type '{ name: string; value: string; namespace: string | null; prefix: null; }' is not assignable to type 'Attribute'. Types of property 'namespace' are incompatible. Type 'string | null' is not assignable to type 'string | undefined'. Type '(element: MockElement) => string | null' is not assignable to type '(element: unknown) => string'. Type 'string | null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'. Type 'ParentNode | null' is not assignable to type 'Node'. Type 'null' is not assignable to type 'Node'. Type 'null' is not assignable to type 'Document'. Type 'string | null | undefined' is not assignable to type 'string | undefined'. Type 'never[] | null' is not assignable to type 'RenderNode[]'. Type 'null' is not assignable to type 'RenderNode[]'. Type 'null' is not assignable to type 'VNode[]'. Type 'null' is not assignable to type 'string | number | undefined'. Type 'null' is not assignable to type 'string | number | Function'. Type 'RenderNode | null' is not assignable to type 'RenderNode'. Type 'null' is not assignable to type 'RenderNode'. Type 'HTMLElement | null' is not assignable to type 'EventTarget'. Type 'null' is not assignable to type 'EventTarget'. Type 'string | null | undefined' is not assignable to type 'string | undefined'. Type 'null' is not assignable to type 'string | undefined'. Type 'null' is not assignable to type 'Set | undefined'. Type 'null' is not assignable to type '[string, any][] | undefined'. Type 'VNode[] | undefined' is not assignable to type 'VNode[]'. Type 'undefined' is not assignable to type 'VNode[]'. Type '(props: {}, children: VNode[], utils: FunctionalUtilities) => null' is not assignable to type 'FunctionalComponent<{}>'. Type 'null' is not assignable to type 'VNode | VNode[]'. Type '() => null' is not assignable to type 'FunctionalComponent<{}>'. Type 'null' is not assignable to type 'VNode | VNode[]'. Type 'null' is not assignable to type 'VNode'. Type 'undefined' is not assignable to type 'VNode'. Type 'RenderNode | undefined' is not assignable to type 'RenderNode'. Type 'undefined' is not assignable to type 'RenderNode'. Type 'RelocateNodeData | undefined' is not assignable to type 'RelocateNodeData'. Type 'undefined' is not assignable to type 'RelocateNodeData'. Type 'ChildNode | null' is not assignable to type 'Node'. Type 'null' is not assignable to type 'Node'. Type 'null' is not assignable to type 'ScreenshotBuild'. Type 'null' is not assignable to type 'ScreenshotCache'. Type 'null' is not assignable to type 'Buffer'. Type 'null' is not assignable to type 'Screenshot'. Type '(() => void) | undefined' is not assignable to type '() => any'. Type 'undefined' is not assignable to type '() => any'. Type '() => null' is not assignable to type '(opts: { rootDir: string; moduleId: string; path: string; }) => string'. Type 'null' is not assignable to type 'string'. Type '() => null' is not assignable to type '(opts: { moduleId: string; path?: string | undefined; version?: string | undefined; }) => string'. Type 'null' is not assignable to type 'string'. Type '() => string | undefined' is not assignable to type '() => string'. Type 'string | undefined' is not assignable to type 'string'. Type 'undefined' is not assignable to type 'string'. Type 'number | null' is not assignable to type 'number'. Type 'null' is not assignable to type 'number'. Type 'any[] | undefined' is not assignable to type 'any[]'. Type 'undefined' is not assignable to type 'any[]'. Type 'boolean | null | undefined' is not assignable to type 'boolean | undefined'. Type 'null' is not assignable to type 'ConfigBundle[] | undefined'. Type 'null' is not assignable to type 'OutputTarget[] | undefined'. Type 'null' is not assignable to type 'TestingConfig | undefined'. Type 'null' is not assignable to type 'Cache'. Type 'null' is not assignable to type '{ access: (filePath: string) => Promise; accessSync: (filePath: string) => boolean; cancelDeleteDirectoriesFromDisk: (dirPaths: string[]) => void; cancelDeleteFilesFromDisk: (filePaths: string[]) => void; ... 17 more ...; writeFiles: (files: { ...; } | Map<...>, opts?: FsWriteOptions | undefined) => Promise...'. Type 'HostRef | undefined' is not assignable to type 'HostRef'. Type 'undefined' is not assignable to type 'HostRef'. Type 'Function | undefined' is not assignable to type 'Function'. Type 'undefined' is not assignable to type 'Function'. Type 'RafCallback | undefined' is not assignable to type 'Function'. Type 'undefined' is not assignable to type 'Function'. Type 'QueuedLoadModule | undefined' is not assignable to type 'QueuedLoadModule'. Type 'undefined' is not assignable to type 'QueuedLoadModule'. Type 'null' is not assignable to type 'ElementHandle'. Type 'null' is not assignable to type 'E2EPageInternal'. Type 'ElementHandle | null' is not assignable to type 'ElementHandle'. Type 'null' is not assignable to type 'ElementHandle'. Type 'ElementHandle | null' is not assignable to type 'ElementHandle'. Type 'null' is not assignable to type 'ElementHandle'. Type 'ElementHandle | null' is not assignable to type 'ElementHandle | null'. Type 'ElementHandle' is not assignable to type 'ElementHandle'. Type 'Node' is missing the following properties from type 'Element': attributes, classList, className, clientHeight, and 110 more. Type 'null' is not assignable to type 'Promise<JSHandle>'. Type '(a?: any, b?: any) => Promise<ScreenshotDiff | undefined>' is not assignable to type '{ (): Promise; (description: string): Promise; (opts: ScreenshotOptions): Promise<...>; (description: string, opts: ScreenshotOptions): Promise<...>; }'. Type 'Promise<ScreenshotDiff | undefined>' is not assignable to type 'Promise'. Type 'ScreenshotDiff | undefined' is not assignable to type 'ScreenshotDiff'. Type 'undefined' is not assignable to type 'ScreenshotDiff'. Type 'null' is not assignable to type 'CompilerWatcher'. Type 'null' is not assignable to type 'Promise'. Type 'Browser | null' is not assignable to type 'Browser'. Type 'null' is not assignable to type 'Browser'. Type 'null' is not assignable to type 'ValidatedConfig'. Type 'null' is not assignable to type 'Browser'. Type 'null' is not assignable to type 'SourceMap'. Type 'null' is not assignable to type 'PackageJsonData'. Type 'null' is not assignable to type '{ [moduleId: string]: string; } | undefined'. |
TS2531 | 203 | Error messagesObject is possibly 'null'. |
TS2454 | 46 | Error messagesVariable 'pkgJsonData' is used before being assigned.Variable 'minifyOpts' is used before being assigned. Variable 'workerCtrl' is used before being assigned. Variable 'timespan' is used before being assigned. Variable 'content' is used before being assigned. Variable 'compilerExe' is used before being assigned. Variable 'outputText' is used before being assigned. Variable 'importResolvedFile' is used before being assigned. Variable 'win' is used before being assigned. Variable 'attrName' is used before being assigned. Variable 'oldValue' is used before being assigned. Variable 'newValue' is used before being assigned. Variable 'hostId' is used before being assigned. Variable 'promise' is used before being assigned. Variable 'textContent' is used before being assigned. Variable 'resolve' is used before being assigned. Variable 'opts' is used before being assigned. |
TS2722 | 41 | Error messagesCannot invoke an object which is possibly 'undefined'. |
TS2352 | 19 | Error messagesConversion of type 'null' to type 'CompilerSystem' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.Conversion of type 'null' to type 'string' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first. Conversion of type 'null' to type 'string[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first. Conversion of type '{ cmps: never[]; }' to type 'Module' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first. Type '{ cmps: never[]; }' is missing the following properties from type 'Module': coreRuntimeApis, collectionName, dtsFilePath, excludeFromCollection, and 27 more. Conversion of type 'null' to type 'ScreenshotCache' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first. |
TS2769 | 12 | Error messagesNo overload matches this call.Overload 1 of 2, '(type: keyof DocumentEventMap, listener: (this: Document, ev: PointerEvent | MouseEvent | UIEvent | Event | ErrorEvent | ... 13 more ... | WheelEvent) => any, options?: boolean | ... 1 more ... | undefined): void', gave the following error. Argument of type '"e"' is not assignable to parameter of type 'keyof DocumentEventMap'. Overload 2 of 2, '(type: string, listener: EventListenerOrEventListenerObject, options?: boolean | AddEventListenerOptions | undefined): void', gave the following error. Argument of type 'null' is not assignable to parameter of type 'EventListenerOrEventListenerObject'. No overload matches this call. Overload 1 of 2, '(o: {}): string[]', gave the following error. Argument of type 'BuildResultsComponentGraph | undefined' is not assignable to parameter of type '{}'. Type 'undefined' is not assignable to type '{}'. Overload 2 of 2, '(o: object): string[]', gave the following error. Argument of type 'BuildResultsComponentGraph | undefined' is not assignable to parameter of type 'object'. Type 'undefined' is not assignable to type 'object'. No overload matches this call. Overload 1 of 4, '(object: {}, method: never): SpyInstance<never, never>', gave the following error. Argument of type 'CompilerWorkerContext | undefined' is not assignable to parameter of type '{}'. Type 'undefined' is not assignable to type '{}'. Overload 2 of 4, '(object: {}, method: never): SpyInstance<never, never>', gave the following error. Argument of type 'CompilerWorkerContext | undefined' is not assignable to parameter of type '{}'. Type 'undefined' is not assignable to type '{}'. No overload matches this call. The last overload gave the following error. Argument of type 'string | null' is not assignable to parameter of type '(substring: string, ...args: any[]) => string'. Type 'null' is not assignable to type '(substring: string, ...args: any[]) => string'. No overload matches this call. The last overload gave the following error. Argument of type 'string | undefined' is not assignable to parameter of type 'string | RegExp'. Type 'undefined' is not assignable to type 'string | RegExp'. No overload matches this call. Overload 1 of 2, '(configFileName: string, optionsToExtend: CompilerOptions | undefined, system: System, createProgram?: CreateProgram | undefined, reportDiagnostic?: DiagnosticReporter | undefined, reportWatchStatus?: WatchStatusReporter | undefined, watchOptionsToExtend?: WatchOptions | undefined, extraFileExtensions?: readonly FileExtensionInfo[] | undefined): WatchCompilerHostOfConfigFile<...>', gave the following error. Argument of type 'string | undefined' is not assignable to parameter of type 'string'. Type 'undefined' is not assignable to type 'string'. Overload 2 of 2, '(rootFiles: string[], options: CompilerOptions, system: System, createProgram?: CreateProgram | undefined, reportDiagnostic?: DiagnosticReporter | undefined, reportWatchStatus?: WatchStatusReporter | undefined, projectReferences?: readonly ProjectReference[] | undefined, watchOptions?: WatchOptions | undefined): WatchCompilerHostOfFilesAndCompilerOptions<...>', gave the following error. Argument of type 'string | undefined' is not assignable to parameter of type 'string[]'. Type 'undefined' is not assignable to type 'string[]'. No overload matches this call. Overload 1 of 2, '(timeoutId: string | number | Timeout | undefined): void', gave the following error. Argument of type 'Timeout | null' is not assignable to parameter of type 'string | number | Timeout | undefined'. Type 'null' is not assignable to type 'string | number | Timeout | undefined'. Overload 2 of 2, '(id?: number | undefined): void', gave the following error. Argument of type 'Timeout | null' is not assignable to parameter of type 'number | undefined'. Type 'null' is not assignable to type 'number | undefined'. No overload matches this call. Overload 1 of 2, '(timeoutId: string | number | Timeout | undefined): void', gave the following error. Argument of type 'Timeout | null' is not assignable to parameter of type 'string | number | Timeout | undefined'. Overload 2 of 2, '(id?: number | undefined): void', gave the following error. Argument of type 'Timeout | null' is not assignable to parameter of type 'number | undefined'. No overload matches this call. Overload 1 of 3, '(p: string, encoding: "utf8"): Promise', gave the following error. Argument of type 'string | undefined' is not assignable to parameter of type 'string'. Type 'undefined' is not assignable to type 'string'. Overload 2 of 3, '(p: string, encoding: "binary"): Promise', gave the following error. Argument of type 'string | undefined' is not assignable to parameter of type 'string'. Type 'undefined' is not assignable to type 'string'. No overload matches this call. Overload 1 of 2, '(values: [] | readonly unknown[]): Promise<unknown[] | []>', gave the following error. Argument of type 'Promise[] | undefined' is not assignable to parameter of type '[] | readonly unknown[]'. Type 'undefined' is not assignable to type '[] | readonly unknown[]'. Overload 2 of 2, '(values: Iterable<void | PromiseLike>): Promise<void[]>', gave the following error. Argument of type 'Promise[] | undefined' is not assignable to parameter of type 'Iterable<void | PromiseLike>'. Type 'undefined' is not assignable to type 'Iterable<void | PromiseLike>'. |
TS2790 | 10 | Error messagesThe operand of a 'delete' operator must be optional. |
TS2538 | 8 | Error messagesType 'undefined' cannot be used as an index type.Type 'null' cannot be used as an index type. |
TS2416 | 5 | Error messagesProperty 'get' in type 'Cache' is not assignable to the same property in base type 'Cache'.Type '(key: string) => Promise<string | null>' is not assignable to type '(key: string) => Promise'. Type 'Promise<string | null>' is not assignable to type 'Promise'. Type 'string | null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'. Property 'getMemoryStats' in type 'Cache' is not assignable to the same property in base type 'Cache'. Type '() => string | null' is not assignable to type '() => string'. Type 'string | null' is not assignable to type 'string'. Type 'null' is not assignable to type 'string'. Property 'find' in type 'E2EElement' is not assignable to the same property in base type 'E2EElementInternal'. Type '(selector: string) => Promise<E2EElement | null>' is not assignable to type '(selector: FindSelector) => Promise'. Type 'Promise<E2EElement | null>' is not assignable to type 'Promise'. Type 'E2EElement | null' is not assignable to type 'E2EElement'. Type 'null' is not assignable to type 'E2EElement'. Property 'findAll' in type 'E2EElement' is not assignable to the same property in base type 'E2EElementInternal'. Type '(selector: string) => Promise<E2EElement[]>' is not assignable to type '(selector: FindSelector) => Promise<E2EElement[]>'. Type 'Promise<import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-element").E2EElement[]>' is not assignable to type 'Promise<import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-declarations").E2EElement[]>'. Type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-element").E2EElement[]' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-declarations").E2EElement[]'. Type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-element").E2EElement' is not assignable to type 'import("/home/runner/work/stencil/stencil/src/testing/puppeteer/puppeteer-declarations").E2EElement'. The types returned by 'find(...)' are incompatible between these types. Type 'Promise<E2EElement | null>' is not assignable to type 'Promise'. Property 'getComputedStyle' in type 'E2EElement' is not assignable to the same property in base type 'E2EElementInternal'. Type '(pseudoElt?: string | null | undefined) => Promise' is not assignable to type '(pseudoElt?: string | null | undefined) => Promise'. Type 'Promise' is not assignable to type 'Promise'. Type 'unknown' is not assignable to type 'CSSStyleDeclaration'. |
TS2533 | 3 | Error messagesObject is possibly 'null' or 'undefined'. |
TS2493 | 3 | Error messagesTuple type '[]' of length '0' has no element at index '0'. |
TS2488 | 2 | Error messagesType 'Diagnostic[] | undefined' must have a 'Symbol.iterator' method that returns an iterator.Type 'string[] | undefined' must have a 'Symbol.iterator' method that returns an iterator. |
TS2774 | 2 | Error messagesThis condition will always return true since this function is always defined. Did you mean to call it instead? |
TS2571 | 2 | Error messagesObject is of type 'unknown'. |
TS2684 | 1 | Error messagesThe 'this' context of type 'ResolveIdHook | undefined' is not assignable to method's 'this' of type 'Function'.Type 'undefined' is not assignable to type 'Function'. |
TS2464 | 1 | Error messagesA computed property name must be of type 'string', 'number', 'symbol', or 'any'. |
TS2430 | 1 | Error messagesInterface 'SerializeOpts' incorrectly extends interface 'SerializeCssOptions'.Types of property 'usedSelectors' are incompatible. Type 'UsedSelectors | null' is not assignable to type 'UsedSelectors | undefined'. Type 'null' is not assignable to type 'UsedSelectors | undefined'. |
Unused exports report
There are 9 unused exports on this PR. That's the same number of errors on main, so at least we're not creating new ones!
Unused exports
File | Line | Identifier |
---|---|---|
src/screenshot/screenshot-fs.ts | 18 | readScreenshotData |
src/testing/testing-utils.ts | 186 | withSilentWarn |
src/compiler/app-core/app-data.ts | 3 | BUILD |
src/compiler/app-core/app-data.ts | 88 | Env |
src/compiler/app-core/app-data.ts | 90 | NAMESPACE |
src/compiler/fs-watch/fs-watch-rebuild.ts | 111 | updateCacheFromRebuild |
src/testing/platform/testing-platform.ts | 29 | cssVarShim |
src/testing/puppeteer/puppeteer-declarations.ts | 485 | WaitForEventOptions |
src/client/polyfills/css-shim/utils.ts | 1 | GLOBAL_SCOPE |
2685c53
to
2a186e7
Compare
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810
61b13d3
to
3dd8ec1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one small callout I wanted to verify
src/sys/node/node-sys.ts
Outdated
puppeteer: { minVersion: '1.19.0', recommendedVersion: '19' }, | ||
'puppeteer-core': { minVersion: '1.19.0', recommendedVersion: '19' }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.19.0
doesn't seem right so just calling out to be safe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope - bad merge conflict resolution. Fixed in 0e4cb95
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this all looks straightforward enough, I ran through the testing steps as well and confirmed that everything looks good. Just had one question about the version range.
@@ -607,8 +607,8 @@ export function createNodeSys(c: { process?: any } = {}): CompilerSystem { | |||
'@types/jest': { minVersion: '24.9.1', recommendedVersion: '27.0.3', maxVersion: '27.0.0' }, | |||
jest: { minVersion: '24.9.1', recommendedVersion: '27.0.3', maxVersion: '27.0.0' }, | |||
'jest-cli': { minVersion: '24.9.0', recommendedVersion: '27.4.5', maxVersion: '27.0.0' }, | |||
puppeteer: { minVersion: '10.0.0', recommendedVersion: '13.5.2' }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we set a max here, like we do for jest
and co?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 done in 303e7a7
this commit increments the supported version of puppeteer from v10 to v14. v11, v12, v13 all did not require any changes to the stencil codebase. as a result, this commit jumps directly from v10 to v14. the package is now declared in `package.json` using a caret ("^") instead of a tilde ("~"). the author (rwaskiewicz) was being cautious when making the change to support v10 of stencil in #2934, to a degree that is no longer necessary v14 of puppeteer introduced private fields in their source code. this affected stencil's validation scripts for type declaration files, as the default settings would create a TypeScript `program` that could not be properly compiled/validated. the `moduleResolution` and `target` fields needed to be explictly set to allow the transpiled `.d.ts` to pass validation. this is a result of cascading defaults where for the `createProgram` call: - the `target` field defaults to "ES3" - the `target` default causes the `module` field to default to "CommonJS" - the `module` default causes `moduleResolution` to default to "classic", which can't resolve the new type declaration file. as a result, we explicitly set this field - the `target` field is set to support the private identifiers in puppeteer
this commit increments the supported version of puppeteer from v14 to v15. starting with puppeteer v15, the library performs type inference/deduction for the `evaluate()` function. this commit updates the types (often removing them) at the advice spelled out in puppeteer/puppeteer#8547.
this commit increments the suppported version of puppeteer from v15 to v16. v16 did not require any changes in the codebase, other than incrementing the list of supported versions of the library.
this commit increments the supported version of puppeteer from v16 to v17. puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity used to run javascript, an internal entity. previously, stencil would directly access retrieve an `ExecutionContext` from a helper function that is no longer exposed. to work around this in puppeteer v17+, two different strategies for getting access to this entity have been added. Each strategy is dependent on how we were previously accessing the `ExecutionContext`. 1. `ElementHandle` Scenario in this scenario, an `ExecutionContext` was being pulled off an `ElementHandle` instance. the suggested way of getting an `ExecutionContext` in puppeteer v17+ for an `ElementHandle` is through the `frame` getter on the `ElementHandle` instance. doing so does not work in puppeteer v16 and below. for those versions of puppeteer v16 and below, stencil will default to the original `executionContext()` behavior. otherwise, the return value of the `frame` getter is returned from a new utility method. in order to determine which version of puppeteer is used, a mechanism for reading the puppeteer `package.json#version` field has been added. this avoids clunky prototype lookups that have been used in the past, and are not always the safest way to detect the version of puppeteer being used (e.g. a field may exist on the prototype chain of an object in 2 different versions of puppeteer, but do very different things). 2. `JSHandle` Scenario accessing a `JSHandle`'s `ExecutionContext` is necessary in `puppeteer-event.ts`. because this is the only instance where stencil would get an `ExecutionContext` from a `JSHandle`, no utility function for retrieving an `ExecutionContext` was created. rather, the same effect can be achieved in a backwards compatible way by calling `evaluate()` directly on the `JSHandle` instance. we do not call `.asElement()` on the `JSHandle` instance and subsequently use the "`ElementHandle` Scenario" described above as a `JSHandle` does not always have an element associated with it, making it impossible to get an `ExecutionContext` in such instances
this commit increments the supported bersion of puppeteer from v17 to v18. puppeteer v18 did not include any breaking changes that required major breaking changes to stencil
this commit increments the supported version of pupeeteer from v18 to v19. there were no breaking changes in puppeteer v19 that required changes to stencil
this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
this commit bumps the version of npm used for the karma test project to npm v7. it also increments the version of node to v14.21. this is required for running the latest version of puppeteer
303e7a7
to
63e3dd6
Compare
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810 this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
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 ports the documentation changes from ionic-team/stencil#3810 (ionic-team/stencil@22c7424) to the v2 version of the stencil site
this commit ports the documentation changes from ionic-team/stencil#3810 (ionic-team/stencil@22c7424) to the v2 version of the stencil site
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810 this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810 this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
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 updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810 this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810 this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810 this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
this commit updates the support table for puppeteer versions for stencil v3. it serves as the documentation for ionic-team/stencil#3810 this commit updates the puppeteer section of the breaking_changes document to clarify the version of puppeteer that is supported
Pull request checklist
Please check if your PR fulfills the following requirements:
npm run build
) was run locally and any changes were pushednpm test
) were run locally and passednpm run test.karma.prod
) were run locally and passednpm run prettier
) was run locally and passedPull request type
Please check the type of change your PR introduces:
What is the current behavior?
GitHub Issue Number: N/A
What is the new behavior?
this pull request adds support for puppeteer v11 through v19.
each commit is described below:
Puppeteer v11, v12, v13
v11, v12, v13 all did not require any changes to the stencil codebase.
Puppeteer v14
the package is now declared in
package.json
using a caret ("^")instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary
v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript
program
that could notbe properly compiled/validated.
the
moduleResolution
andtarget
fields needed to be explictlyset to allow the transpiled
.d.ts
to pass validation. this is a resultof cascading defaults where for the
createProgram
call:target
field defaults to "ES3"target
default causes themodule
field to default to"CommonJS"
module
default causesmoduleResolution
to default to"classic", which can't resolve the new type declaration file. as a
result, we explicitly set this field
target
field is set to support the private identifiers inpuppeteer
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 updatesthe types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.
Puppeteer v16
v16 did not require any changes in the codebase, other than incrementing
the list of supported versions of the library.
Puppeteer v17
this commit increments the supported version of puppeteer from v16 to v17.puppeteer v17 made accessing a puppeteer
ExecutionContext
, an entityused to run javascript, an internal entity. previously, stencil would
directly access retrieve an
ExecutionContext
from a helper functionthat 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
.ElementHandle
Scenarioin this scenario, an
ExecutionContext
was being pulled off anElementHandle
instance.the suggested way of getting an
ExecutionContext
in puppeteer v17+ foran
ElementHandle
is through theframe
getter on theElementHandle
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 theframe
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).
JSHandle
Scenarioaccessing a
JSHandle
'sExecutionContext
is necessary inpuppeteer-event.ts
. because this is the only instance where stencilwould get an
ExecutionContext
from aJSHandle
, no utility functionfor retrieving an
ExecutionContext
was created. rather, the sameeffect can be achieved in a backwards compatible way by calling
evaluate()
directly on theJSHandle
instance.we do not call
.asElement()
on theJSHandle
instance andsubsequently use the "
ElementHandle
Scenario" described above as aJSHandle
does not always have an element associated with it, making itimpossible to get an
ExecutionContext
in such instancesPuppeteer v18
puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil
Puppeteer v19
puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil
Node, NPM versions
this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm
Does this introduce a breaking change?
Testing
This branch will be used for all manual testing.
Step 0 - Verify Type Checking on Stencil
Create
test-pptr-w-tsc.sh
in the root of the Stencil repo with the following contents:Run the script
./test-pptr-w-tsc.sh
. This will verify that if we need to roll back the version of puppeteer, the code type checks in a backwards compatible way. Note, this step only checks the type checking, not the impl details of puppeteer and how they integrate with StencilStep 1 - Build this Branch
After completing Step 0, be sure to
git reset --hard
to restore anything that changedTo build it, checkout this branch and run the following:
Note the path of the created tarball. We'll use that and refer to it as
TARBALL_PATH
Step 2 - Smoke Test
create-stencil
OutputCreate a small Stencil component library:
In the root of the
pptr/
dir, createtest-version.sh
with the following:Finally, run
./test-version.sh <TARBALL_PATH>
. This will exercise the output of thecreate-stencil
cli against the latest release for every major version of Puppeteer, starting with v10 and ending in v19. For all 10 versions, you should see something like:Step 3 - Test this Branch as a Drop-In Replacement for Stencil in Ionic Framework
Check out the Ionic Framework repository, and install this branch of Stencil in core.
We want to test that Puppeteer v10 works in the Ionic Framework with our changes from this branch applied. To do so, run the e2e tests:
if everything passes, please move on to Step 4. It uses the work we just did.
Step 4 - This this Branch with Puppeteer v10->v19 in Ionic Framework
Before starting this step, complete all instructions for Step 3
In this step, we want to use the Ionic Framework as an example of a mature codebase using the E2E testing suite. We'll use a script to install each version of Puppeteer and run the test suite against our Stencil build and a specific version of Puppeteer.
To automate this process, create
test-pptr-framework.sh
in thecore/
directory of the Ionic Framework repo you have:And run it with
./test-pptr-framework.sh
. The tests should pass for each version.However! Please note:
Other information
Why Does this PR Target Stencil v3? Why Not Add this to v2?
Puppeteer v14 dropped support for Node 12, which Stencil v2 still supports. We still have users on Node 12 (as well as our CI pipeline testing against it for them), making it impossible to merge this without forcing it (and subsequent PRs) or removing Node 12 checks from the pipeline.