zploskey / bs-puppeteer Goto Github PK

Upstream commit: puppeteer/puppeteer@35e34db

Depends on next puppeteer version (probably 1.3).

The devDependency bs-platform was updated from 4.0.6 to 4.0.7.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

bs-platform is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Just add a statusText getter.

Puppeteer commit: puppeteer/puppeteer@7f9e276

I've been observing this test failure recently on Fedora 27.

 FAIL  lib/js/__tests__/puppeteer_test.js (33.889s)
...
  ● BrowserFetcher › remove

    Timeout - Async callback was not invoked within the 30000ms timeout specified by jest.setTimeout.
      
      at node_modules/jest-jasmine2/build/queue_runner.js:68:21
      at Timeout.callback [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:633:19)

This doesn't happen on Travis, which is also Linux, but is a bit of an annoyance when developing locally, especially because we run tests in the precommit hook. I'm curious if anyone else can reproduce. This is a reminder (mostly for myself) to look into this and try to tweak things so that all tests pass.

Tasks for a release following the Puppeteer 1.2.0 release which is expected on March 15th.

• #23: ElementHandle.contentFrame()
• #35: addScriptTag can can take a script type
• Bump Puppeteer version
• Update changelog
• Ship new version

Any additional API changes should be included here.

while running the examples/search.re code it throws the following error, which I would like to understand how to fix:

  We've found a bug for you!
  /Users/prisc_000/Downloads/bs-puppeteer/examples/src/search.re 27:16-73

  25 ┆ /* Wait for suggestion overlay to show up then click "all results". */
  26 ┆ |> then_(_ => page->Page.waitForSelector(allResultsSelector, ()))
  27 ┆ |> then_(elmt => Js.Null.getExn(elmt)->ElementHandle.click())
  28 ┆ /* Wait for load of results page. */
  29 ┆ |> then_(() => {

  This has type:
    Js.Promise.t(Js.Null.t(BsPuppeteer.ElementHandle.t('a))) =>
    Js.Promise.t(unit)
  But somewhere wanted:
    Js.Promise.t(unit) => 'b

  The incompatible parts:
    Js.Promise.t(Js.Null.t(BsPuppeteer.ElementHandle.t('a))) (defined as
      Js.Promise.t(Js.Null.t(BsPuppeteer.ElementHandle.t('a))))
    vs
    Js.Promise.t(unit) (defined as Js.Promise.t(unit))

    Further expanded:
      Js.Null.t(BsPuppeteer.ElementHandle.t('a)) (defined as
        Js.null(BsPuppeteer.ElementHandle.t('a)))
      vs
      unit

FAILED: subcommand failed.
>>>> Finish compiling(exit: 1)

Thank you.

Should go in src/Target.re.

We have a number of functions that can be used to evaluate an arbitrary javascript function in the browser context. If a Bucklescript-generated function is passed in, quite often it will depend on imports from Bucklescript that won't be available in the browser context. For example, anything which deals with option/null values will need to import Js_primitive, or they may need Curry, etc. Bucklescript previously didn't have a special import for basic checking of options but it seem to have changed that recently. These imports need to be loaded in the browser context, probably with Page.addScriptTag.

Apparently local dependencies can be loaded with javascript like this:

await page.addScriptTag({path: require.resolve('jquery')})

We should provide a way to easily load any relevant Bucklescript imports into the browser. Some of these should probably be loaded by default. Furthermore, we should document how to load the user's own library code or external js libraries into the page so that it can be used in eval functions. This is something that normal Puppeteer users may have to do, but it is a more frequent/immediate need for BS users. In particular I would expect bs-webapi will probably see a lot of use just to be able to do basic dom manipulation.

We may want to look into compiling a minified version of at least a subset of BS so that more of these functions will work without extra hassle.

Upstream commit: puppeteer/puppeteer@98bb261

https://github.com/GoogleChrome/puppeteer/blob/v1.2.0/docs/api.md#class-coverage

puppeteer/puppeteer#2090

Upstream commit: puppeteer/puppeteer@94c32e4

Depends on development version of puppeteer but should be in their next release.

This should be included in Puppeteer 1.2.0 which is expected to be released on March 15th.

Docs

We should put this function and its variations in FrameBase so that we don't need to repeat it for Page and Frame.

https://pptr.dev/#?product=Puppeteer&show=api-framewaitforfunctionpagefunction-options-args

May not be a need for a version that takes a string.

https://github.com/GoogleChrome/puppeteer/releases/tag/v1.1.0

Upstream commit: puppeteer/puppeteer@23d25a6

Page.pdf() needs an implementation similar to other several other functions that take options objects, like Puppeteer.launch(). This would involve creating a type Page.pdfOptions and a [@bs.obj] annotated external Page.makePDFOptions(). Like the other examples already implemented, we'll wanted to create another function with the same name to shadow the external Page.makePDFOptions. It will convert to JS types--in particular bool needs to be converted to Js.boolean. We can use the helper functions in our Util module for that.

Docs

The Typescript definitions are a good reference here. They list all the possible values of the string enum pdfFormat which we'll probably want to handle using [@bs.string]. Searching for "pdf" on that should lead to the relevant definitions.

Also, the Pdf module can be removed as we should just put this all in the Page module.

Upstream release notes: https://github.com/GoogleChrome/puppeteer/releases/tag/v1.10.0

Specifically these changes are needed:

• Browser.waitForTarget (puppeteer/puppeteer@6ac66c3)
• BrowserContext.waitForTarget (puppeteer/puppeteer@6ac66c3)
• Bind to page.accessibility (puppeteer/puppeteer@9ba3261)

Need to bind to $eval, $$eval and evaluate.
Suggested names selectEval, selectAllEval, and evalute should be fine to keep the same.

Since the names need adjustment from upstream anyway, would be open to suggestions. Possibly selectMap and selectAllMap? But keeping eval in the name makes the correspondence with the upstream API more clear.

References:
Typescript definitions: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/puppeteer/index.d.ts
API Documentation:
https://github.com/GoogleChrome/puppeteer/blob/v1.1.0/docs/api.md

We should force handling the null case, converted to option.

See: puppeteer/puppeteer@6ca43cf

I don't find any way to use the dialog? reading https://pptr.dev/#?product=Puppeteer&version=v1.8.0&show=api-class-dialog it seems that I should use Page.on, but that's not implemented?

Upstream commit: puppeteer/puppeteer@93fe2b5

https://pptr.dev/#?product=Puppeteer&version=v1.5.0&show=api-class-worker

Puppeteer commit: puppeteer/puppeteer@30338a0

Puppeteer commit: puppeteer/puppeteer@231a2be

We should at least bind to the new methods.

Puppeteer commit: puppeteer/puppeteer@464f3b4

Puppeteer 1.9 was just released. We should bind to what was added.

Puppeteer 1.9 Release Notes

https://github.com/GoogleChrome/puppeteer/blob/v1.2.0/docs/api.md#class-cdpsession

Similar functions are in FrameBase with names starting with selectAllEval, so this naming should be kept consistent.

This feature was added in Puppeteer 1.4. Puppeteer commit: puppeteer/puppeteer@88b9968

The devDependency bs-platform was updated from 4.0.9 to 4.0.10.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

bs-platform is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

We are missing doc comments for a lot of the bindings. Adding them really improves the developer experience in the editor and will eventually allow us to generate some API documentation. We'll check off documented modules as they are done.

• BoundingBox
• BoxModel
• Browser
• BrowserContext
• BrowserFetcher
• CDPSession
• Click
• ConsoleMessage
• Coverage
• Dialog
• ElementHandle
• Evaluator
• ExecutionContext
• Frame
• FrameBase
• JSHandle
• JSMap (may eventually be split off into a separate package)
• Keyboard
• Metrics
• Mouse
• Navigation
• Page
• Puppeteer (partially documented)
• Request (partially documented)
• Response
• Screenshot
• SecurityDetails
• Target
• Touchscreen (and some more binding implementation)
• Tracing
• Types
• Unit
• Util
• Worker

For now we should focus on getting the most important information into doc comments on the main functions and types of each modules. Don't worry too much about formatting until things have standardized somewhat. Short doc comments may need to be padded out some until Reason 3.3+ is released with my fix to doc comment formatting before externals (reasonml/reason@1502999).

I was trying to extract some attributes in a selectAllEval case and had to end up with using bs.raw and this code: return Promise.resolve(nodes.map(node => node.getAttribute("href")));

I tried to use bucklescript with Webapi but bucklescript inject things like transfering to option and that code is not known in the browser context of course. I'm not sure this is something you can fix, but I was wondering if there is a better way of handling this?

https://github.com/GoogleChrome/puppeteer/blob/v1.2.0/docs/api.md#class-dialog

Release notes: https://github.com/GoogleChrome/puppeteer/releases/tag/v1.11.0

There were not a lot of changes here. It mostly involves adding an optional options parameter to Page.setContent.

Puppeteer commit: puppeteer/puppeteer@726c8dc

https://github.com/GoogleChrome/puppeteer/blob/v1.1.1/docs/api.md#tracingstartoptions

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The devDependency lint-staged was updated from 10.1.2 to 10.1.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

lint-staged is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

https://github.com/GoogleChrome/puppeteer/blob/v1.2.0/docs/api.md#class-browserfetcher

Upstream change: puppeteer/puppeteer@3b03ff6

https://pptr.dev/#?product=Puppeteer&version=v1.5.0&show=api-class-browsercontext

In our use case we ought to have access to a huge list of browser events, since Browser implements EventEmitter.

There's some work done on this in bs-webapi: https://github.com/reasonml-community/bs-webapi-incubator/tree/master/src/dom/events

There is an implementation in OCaml of Node's EventEmitter here: https://github.com/freebroccolo/bucklescript-electron/blob/master/src/electron.ml

These approaches aren't compatible in their Reason APIs. I think you're starting to see that this is a can of worms. The community would really benefit if we can standardize this is some way. We should maybe think about putting it in its own package or part of the a collection of Node bindings that might get incorporated into the stdlib like @reasonml-community's bs-node.

Upstream commit: puppeteer/puppeteer@41d5838

Hi, I see you have fixed the use of methodToJs in Request.re that prohibits to build the package with current bs-platform (7.2.2). However, in redex/package index the newest version is 0.12 - which does not contain this fix. Could You please make a release?

Thanks for doing this work! ⭐

Puppeeteer commit: puppeteer/puppeteer@50d6c2d

We may need to increase the timeout on browser creation specifically so they will consistently work on Travis. It looks like maybe there is an intermittent timeout or some other kind of failure on creating the browser, that later makes the tests fail that try to use the reference to the browser instance.

For example: https://travis-ci.org/bs-puppeteer/bs-puppeteer/builds/348310573

One of the js errors:

    TypeError: browser[0].userAgent is not a function

      55 |               }));
      56 |         Jest.testPromise(/* None */0, "userAgent()", (function () {
    > 57 |                 return browser[0].userAgent().then((function (userAgent) {
      58 |                               return Promise.resolve(Jest.Expect[/* toContainString */11]("HeadlessChrome", Jest.Expect[/* expect */0](userAgent)));
      59 |                             }));
      60 |               }));

Potential points of failure that ought to be investigated are the jest timeout and the default timeout for creating the browser instance (Launcher.makeLaunchOptions(~timeout)).

Puppeteer commit: puppeteer/puppeteer@40466cb

Some of these functions have names we cannot use, containing $. Seems reasonable to call them variations of select. Other than necessary naming adjustments, we have more or less been following the typescript definitions. Some of these may already have stubs, but should be changed to use [@bs.send.pipe : t].

Typescript definition --> suggested name
$(selector: string): Promise<ElementHandle | null>; --> selectOne
$$(selector: string): Promise<ElementHandle[]>; --> selectAll

  waitForSelector(
    selector: string,
    options?: { visible?: boolean; hidden?: boolean; timeout?: number }
  ): Promise<ElementHandle>;

--> same name, options should be type selectorOptions created with a special creation function with all optional parameters.

Wouldn't be opposed to just calling these querySelect or querySelector, which is what it is calling in the frame/page.

References:
Typescript definitions: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/puppeteer/index.d.ts
API Documentation:
https://github.com/GoogleChrome/puppeteer/blob/v1.1.0/docs/api.md

NOTE: The page interface should have a different select() function, which checks <options>s in a <select>.

@jihchi was independently working on some bindings at https://github.com/jihchi/bs-puppeteer-legacy. It makes sense to move over the ones we are missing here. Preferably we do this one feature at a time and give an opportunity to review the API choices before merging.

Puppeteer commit: puppeteer/puppeteer@1702928

Hopefully we can do this once type-first pipe syntax with |. lands in BuckleScript. Then we'll have to do a release that changes all bs.send.pipe annotations to bs.send with t in the first position and include instructions to change the pipe operator to |. instead of |> in code calling our library functions.