Potential v7 breaking changes

[devoto13]

This issue is to track potential improvements to Karma, which require breaking changes. It will be updated with more points as I discover them.

• Drop support for IE < 11 and other obsolete browsers to simplify Karma code and allow using more modern JS in the client code. I think it is reasonable to support same set as Angular does, but open for suggestions.
  • Use the Array.prototype.includes() method instead of a full-fledged for-loop in

    karma/client/karma.js

    Line 242 in 6b3bf3b

    // TODO(https://github.com/karma-runner/karma/issues/3503): replace the for-loop below with the `Array.prototype.includes()` method, when dropping support for IE.

  • Update mocha - it is currently used for cross-browser testing and hence blocked
  • Switch from socket.io to ws to simplify code and reduce amount of dependencies (WebSockets are supported in any reasonably alive browsers, so it may be a good point for a switch as we no longer need fallback mechanisms with only IE 11 supported) - may not do that given that not all proxies, e.g. BrowserStack Local support WebSockets
    • Remove buffering logic for test results (Buffering/batching client messages results in out of order events #3684)
• Remove deprecated customFileHandlers provider once ecosystem is ready
• Remove support for http2 module. It was implemented over a long deprecated https://yarnpkg.com/package/http2 package. WebSockets in general (WebSocket over HTTP2 websockets/ws#1458) and socket.io, in particular, do not work over HTTP/2 (ECONNRESET with HTTP/2 upgrade RST socketio/socket.io#3564). Node's http2 module is not compatible with http and https, so we'll have to build some complex adapters. And on top of that, the current implementation does not seem to work at the moment (Http2 module -> Chrome ERR_SSL_VERSION_OR_CIPHER_MISMATCH error #2761).
• Drop Node 10 support as it is reaching EOL (https://nodejs.org/en/about/releases/) and blocks dependency updates (chore: update tooling packages to the latest versions #3686)
  • Update "@commitlint/config-angular" as mentioned in build: use matching commitlint config #3719 (comment).
• Remove parseConfig() flags introduced in feat: support asynchronous config.set() call in karma.conf.js #3660 and feat(config): improve karma.config.parseConfig error handling #3635 and enable behavior by default
• Make parseConfig() resolve configFile path relative to the CWD instead of relative to the karma/lib/config.js to make programmatic API and CLI work the same (basePath does not work properly in some circumstances #1636)
• Resolve relative plugin paths relative to the basePath or CWD for consistent resolution using both CLI and programmatic approaches
• Remove jsVersion configuration property support.
• Remove mkdirp dependency and use docs instead (See fix(helper): make mkdirIfNotExists helper resilient to concurrent calls #3750).
• Include Significantly improved addFile/changeFile/removeFile performance. #3726.
• AI in d9dade2.
• Consider listening on IPv6 by default. See Karma + Node.js 17: can't connect to karma server. There is no server listening on port 9876 #3730 (comment).

[devoto13]

@johnjbarton Since we merged #3586 with the breaking change, next release will be 6.0.0. What do you think about the points described in this issue? I'm thinking to start opening PRs for them, ending with "Drop support for legacy browsers", which should fix CI on master (currently fails in Safari 9) and publish 6.0.0 containing all the breaking changes in one release.

[johnjbarton]

Some of these would be great. The ws one seems like it could take a bit to get right. Let me check on IE<11.

At present it seems like our semantic release is broken. So to prevent a release I need to stop trying to get it work or otherwise disable it. I'll look in to the latter.

I don't want to wait too long however.

[devoto13]

No problems. I'll try to get PRs up in the coming days.

[devoto13]

@johnjbarton Created a PR for deprecated API removal (actually there were not so much to remove 😄).

Everything else described in this issue depends on the dropping of legacy browsers support, so I'll wait for the confirmation that we can actually drop this support before I start implementing the rest.

[johnjbarton]

I think we should stick with the shorter list for v6, including the reconnect changes I am working on. We can then start v7 immediately focusing on the IE<11 code. Any v6 issues will be cleared up then.

[johnjbarton]

Ok I think that when I land #3598 the releases will start. If not then I will focus on why not.
Plan to land #3601 and #3585 first, after reviews.

[jehon]

If you land #3605 too, you can say that v6 will have full module support... :-)

[johnjbarton]

I believe that #3609 will cause the release to happen. But then again I said that before....

[XhmikosR]

I was looking at the dependencies, and maybe http2 is redundant too?

[devoto13]

@XhmikosR Yes, I agree. See "Remove support for http2 module."` checkbox in the issue.