chore: use private fields

[jrandolf]

This PR changes all underscored fields/methods into private fields and underscores (and labels as internal) all cross-module, camelCase, internal fields/variables/methods.

[smashah]

I understand that this is js convention, however what other reasoning is there for this PR? Lots of dependent projects need to use HTTPRequest._client or Page._client.

[OrKoN]

@smashah to maintain the project we want to clearly separate the public API from internals. In this case, dependent projects were using the undocumented internal API. Please file a issue for your use case and we will try to expose the API in a documented and sustainable way. Btw, the Page._client() is still there.

[smashah]

Thanks for the explanation @OrKoN

I have submitted #8545 to resolve an urgent use case

[casey6]

I was a little disappointed to discover that this breaking change made it into a minor release (14.4.0) completely undocumented and missing from the release notes.

I have some simple code that proxies a Page instance, which now throws a type error Cannot read private member from an object whose class did not declare it. 😞

[jrandolf]

@casey6 This is not a breaking change unless you use internal code which is always subject to breaking changes. If there is public behavior that we amended, please submit an issue and we can try to accommodate. That being said, we do have some places unlabeled with @internal, so that also might have been the problem. If such is the case, we apologize.

[casey6]

I'm simply proxying the page instance, not using any internal code:

const proxiedPage = new Proxy(page, {
  get(page, property) {
    // intercept screenshot calls to override the path property
    if (property === 'screenshot') {
      return async (options = {}) => {
        const filename = options.path?.split('/').pop() ?? `${Date.now()}.png`

        return await page.screenshot({
          ...options,
          path: `/path/to/${filename}`
        })
      }
    }

    return page[property]
  }
})

[jrandolf]

Ah, I see... This is a well-known issue: tc39/proposal-class-fields#106. If I recall, there is a solution using inheritance.