feat: allow to reuse a browser by passing a browserContext

[daniel-hauser]

This pull request changes the page creation logic by alowing a browserContext to be passes instead of a browser (that is currently being closed when the scraping ends)

Copilot reviewed 3 out of 3 changed files in this pull request and generated no suggestions.

[Copilot]

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (3)

src/scrapers/base-scraper-with-browser.ts:85

• [nitpick] The word 'bang' might be confusing. It would be clearer to use 'exclamation mark (!)' instead.

NOTICE - it is discouraged to use bang (!) in general.

src/scrapers/base-isracard-amex.ts:33

• The ExtendedScraperOptions interface was removed, but there was no mention of its removal in the context provided. Ensure that this interface is not used elsewhere in the codebase.

type CompanyServiceOptions = {

src/scrapers/base-isracard-amex.ts:258

• [nitpick] The parameter name 'options' is of type 'CompanyServiceOptions'. It would be clearer to rename it to 'companyServiceOptions'.

async function getExtraScrapTransaction(page: Page, options:CompanyServiceOptions, month: Moment, accountIndex: number, transaction: Transaction): Promise<Transaction> {

[baruchiro]

Please explain how one ScraperOptions interface became to be a union of three interfaces with another fourth interface.

Sorry, something is not clear here, as you can see.

Maybe it is naming only, but it is not clear to me what is the difference between ExternalBrowserOptions and ExternalBrowserContextOptions, do are they both new ways to reuse a browser?
And if they are, why is there a third interface DefaultBrowserOptions? I guess this is the regular way of launching a new browser for each scraper.

Now after your change it is clear there are two different things inside one interface: Browser Settings and Scraping Settings. Maybe we need to split the interfaces or at least insert one of the subjects inside a property (scrapeConfig: ScrapeConfig) in the other one.

[daniel-hauser]

Please explain how one ScraperOptions interface became to be a union of three interfaces with another fourth interface.
...
Maybe it is naming only, but it is not clear to me what is the difference between ExternalBrowserOptions and ExternalBrowserContextOptions, do are they both new ways to reuse a browser?

The code had two ways to create a page:

1. The default way - the scraper creates the browser, the caller can supply some options for the creation.
   • Named DefaultBrowserOptions in this PR
2. The non-default way - the caller supplies an external single use browser (because browser.close() is called)
   • Named ExternalBrowserOptions in this PR

In this PR i added the third way, where the caller only supplies a BrowserContext and is responsible for the browser creation and teardown (named ExternalBrowserContextOptions)

Now after your change it is clear there are two different things inside one interface: Browser Settings and Scraping Settings. Maybe we need to split the interfaces or at least insert one of the subjects inside a property (scrapeConfig: ScrapeConfig) in the other one.

In order to stay backwards compatible, I didn't want to add a new browserOptions property to ScraperOptions, therefore left it as export type ScraperOptions = ScraperBrowserOptions & { ... /* All non-browser options */ }