Making k6/experimental/browser module part of k6 core

[ankur22]

What

Migrate the browser module out of experimental:

k6/experimental/browser -> k6/browser

Why

For this to be achievable the aim is to make the browser module:

1. stable during the runtime;
2. have a stable API.

Some of our users will not want to work with an experimental module with the fear that the cost of maintaining many scripts and breaking changes out weighs the pros of working with the browser module. Graduating the browser module out of experimental will signal to those users that:

1. The APIs are backwards compatible, and the upmost effort will be put into ensuring we don't break this;
2. No major breaking changes are coming to the APIs;
3. There are no known major issues.

Blockers

We need to finalize and possibly work on the following points before we can be ready to graduate browser out of experimental:

Tasks

Beta Give feedback

1. Should browser options be shortened (#3310)? Not now, we need more feedback.
2. Do all xk6-browser APIs need to be converted to async? Yes they do
3. Update the roadmap.
4. Does xk6-browser need to be more compatible with Playwright APIs?
5. If we haven't reached enough of a compatibility with Playwright, what is enough?
6. Are we expecting any major breaking changes?
7. Is xk6-browser going to support multiple browsers other than chromium/chrome?
8. Are there any major issues that must be resolved (e.g. #971)?
9. Browser: Runtime stability #1138
   16 of 29
   epic team/k6browser +2
   
10. Are there any major refactors coming up that could destabilize the module?
11. Async APIs #428
    8 of 23
    async epic feature playwright +4
    

    
12. Migrating to k6-core's linter #1292
    0 of 4
    ci compatibility security +3

[inancgumus]

Nice list of tasks 👍 I'd also like to add the following.

Are there any major refactors coming up that could destabilize the module?

I wouldn't say "to destabilize". But:

• We have a few big refactorings in the pipeline.
• We also might have Low test coverage #228 wrapped up for stabilizing and cementing our code choices. This can also help us fearlessly refactor as well.
• We also have this epic issue: Non-iterational goroutines should not abort an iteration #688.

Do all xk6-browser APIs need to be converted to async? #428

There are open issues other than #428 tagged with async supports async (promises) that we might want to discuss.

If we haven't reached enough of a compatibility with Playwright, what is enough?

This issue tracks PW compatibility #784. Marie has an updated document based on this issue that we can work on to decide what is enough.