Adding custom capabilities to the browserInfo.

[tanishqbhadouria]

Hi,
We wanted to generate the network logs and debug logs when tests run in pipeline, found out that there is no explicit configuration for that in the runner.
In webdriver.js i saw that browserOptions are passed already if we add a capabilities object in that and in webdriver.js if we set those capabilities we could use custom capabilities.
We could use it like

example
browser : {
            name: 'chrome',
            capabilities: {
                'goog:chromeOptions': {
                    args: [
                        '--enable-logging=stderr',
                        '--enable-logging=stdout',
                        '--log-level=0',
                        '--v=1',
                        '--enable-logging',
                        '--net-log-level=0',
                        `--log-net-log=${chromeNetLogFile}`
                    ]
                }
            }
        }

I tried that on my end and it works and if it seems like a useful feature can that be added to the jasmine-browser-runner?

Also I saw your comment about web-test-runner, we are trying to migrate from karma web-test-runner and jasmine-browser-runner were the two successors for karma but I don't actually know the progress of web-test-runner for jasmine, and it is already more than two years when announcement was made, need your advice that should we wait for that or should we stick to our migration from karma to jasmine-browser-runner.

Thanks,
Tanishq

[sgravrock]

The tricky thing is that any change to the capabilities provided by jasmine-browser-runner could potentially be a breaking change. Suppose that there was some change to Chrome that meant that jasmine-browser-runner had to pass a new --enable-turbo-encabulator option. If you had overridden the goog:chromeOptions capability, then that would be a breaking change for you: your previously valid configuration would no longer work.

Some options I can see:

1. Allow users to override capabilities, and do a major release every time jasmine-browser-runner needs to change the capabilities it passes. I don't like this because it means that a niche features makes everyone have to deal with a major version bump.
2. Allow users to override capabilities, but put the burden of compatibility on users and make that very obvious. E.g. call the property unstableSemverExemptOverrideCapabilities or something similarly obnoxious.
3. Something more targeted to individual use cases like generating logs. Drawback: only kills one bird with each stone.

[sgravrock]

I don't actually know the progress of web-test-runner for jasmine, and it is already more than two years when announcement was made, need your advice that should we wait for that or should we stick to our migration from karma to jasmine-browser-runner.

If you're not an Angular user, there's https://github.com/blueprintui/web-test-runner-jasmine. It looks fairly new, but using and contributing to it is probably your best option if you think that web-test-runner fits your needs better than jasmine-browser-runner.

If you are an Angular user, it looks like initial support for web-test-runner was released in Angular 17.1.. The implementation looks about as mature as web-test-runner-jasmine. I don't know what the Angular team's long-term plans for it are. In particular, I don't know whether they'll continue to maintain it if their effort to integrate Vitest succeeds.

[sgravrock]

I don't know what the Angular team's long-term plans for it are. In particular, I don't know whether they'll continue to maintain it if their effort to integrate Vitest succeeds.

They intend to remove it: angular/angular-cli#31946 (comment)

[tanishqbhadouria]

The tricky thing is that any change to the capabilities provided by jasmine-browser-runner could potentially be a breaking change. Suppose that there was some change to Chrome that meant that jasmine-browser-runner had to pass a new --enable-turbo-encabulator option. If you had overridden the goog:chromeOptions capability, then that would be a breaking change for you: your previously valid configuration would no longer work.

I completely understand the concern about breaking changes. You are right—if I simply replace the goog:chromeOptions object with my own, I would lose any new critical flags (like your --enable-turbo-encabulator example) that you might add in a future release.

However, I think we can solve that specific problem by treating user capabilities as additive rather than replacements, specifically for nested arrays like args.

If we implement a merge strategy where user-provided args are concatenated with the preset's default args, we avoid the breaking change scenarios, jasmine-browser-runner defaults are always preserved if any new option is added by you in future, it will not be overwritten.
By this way the user will get the flexibility to add capabilities.

And seeing web-test-runner's progress I don't think that is as mature and future proof for the jasmine.
If we intend to keep the jasmine-browser-runner a simple and lightweight runner there are no good options available for jasmine for runner.
By keeping the default configurations in place but allowing users to extend them when needed, we can serve both simple and advanced use cases effectively.