Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: export public types only #8584

Merged
merged 1 commit into from Jun 27, 2022
Merged

feat: export public types only #8584

merged 1 commit into from Jun 27, 2022

Conversation

jrandolf
Copy link
Contributor

@jrandolf jrandolf commented Jun 27, 2022

This PR does a few things:

  • All exported artifacts are labeled with an accessor tag (@internal, @public, etc).
  • The types.ts file (originally called api-docs-entry.ts) is auto-generated using utils/export-all.js.
  • api-extractor only extracts non-@internal types.
  • Several proxy properties of Puppeteer are deprecated and encourage importing them directly from 'puppeteer'.
  • Some comments are fixed.
  • Some internal symbols have been renamed.

src/types.ts Show resolved Hide resolved
@jrandolf jrandolf merged commit 7001322 into main Jun 27, 2022
@jrandolf jrandolf deleted the export_types branch June 27, 2022 07:24
@stevenwdv
Copy link

stevenwdv commented Jun 28, 2022

Does this mean that it's not possible to access the RemoteObject of a JSHandle anymore? (Or at least not without unsound casts.)
Because in that case, you could consider creating a way to somehow still access (parts of) it. It can actually be pretty useful for stuff like this:

A function that recursively unwraps handles unless they are handles to things that do not make sense unwrapped (functions, Nodes), which it leaves as JSHandles/ElementHandles.

For example, it transforms JSHandle<{elem: Element, score: number}[]> to {elem: ElementHandle<Element>, score: number}[].

async function unwrapHandle<T>(handle: JSHandle<T>): Promise<UnwrappedHandle<T>> {
	return await unwrapHandleEx(handle, () => true) as UnwrappedHandle<T>;
}

async function unwrapHandleEx<T>(handle: JSHandle<T>, shouldUnwrap: (className: string) => boolean = className => ['Object', 'Proxy'].includes(className)):
	  Promise<UnwrappedHandleEx<T>> {
	//XXX Replace _remoteObject with stable version if ever available

	// Leave functions & symbols wrapped
	if (['function', 'symbol'].includes(handle._remoteObject.type))
		return handle as UnwrappedHandleEx<T>;

	if (handle._remoteObject.type === 'object') {
		if ([undefined, 'proxy'].includes(handle._remoteObject.subtype)) {
			if (shouldUnwrap(handle._remoteObject.className!))
				return Object.fromEntries(await Promise.all([...await handle.getProperties()]
					  .map(async ([k, v]) => [k, await unwrapHandleEx(v, shouldUnwrap)]))) as UnwrappedHandleEx<T>;
		} else {
			if (handle._remoteObject.subtype === 'null')
				return null as UnwrappedHandleEx<T>;
			if (handle._remoteObject.subtype === 'array')
				return await Promise.all([...await handle.getProperties()]
					  .map(async ([, v]) => await unwrapHandleEx(v, shouldUnwrap))) as UnwrappedHandleEx<T>;
		}
		return handle as UnwrappedHandleEx<T>;

	} else  // Return other types such as numbers, booleans, bigints, etc. unwrapped
		return (handle._remoteObject.type === 'undefined'
			  ? undefined
			  : handle._remoteObject.value
			  ?? (handle._remoteObject.unserializableValue
					? eval(handle._remoteObject.unserializableValue)  // You may want to use a map here instead
					: await handle.jsonValue())) as UnwrappedHandleEx<T>;

(UnwrappedHandle* types excluded for brevity, but you can have them if you want)

@niieani
Copy link

niieani commented Jun 30, 2022

Another problem this created is that because Protocol is not exported, the consumer needs to keep devtools-protocol version in sync with the one used by puppeteer, at least if they don't want to reach into a transitive dependency (i.e. undeclared in package.json).

Example where this is an issue: https://github.com/niieani/puppeteer-intercept-and-modify-requests/pull/4/files

@OrKoN
Copy link
Collaborator

OrKoN commented Jun 30, 2022

@jrandolf could you please take a look? I think it makes sense to export Protocol too and create a documented way to access the remote object.

@jrandolf
Copy link
Contributor Author

jrandolf commented Jul 1, 2022

@niieani @stevenwdv Could you please file an issue for what you are requesting?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants