fix(tests): minor fix for transportMode.client test case

[jamesgeorge007]

• This is a bugfix
• This is a feature
• This is a code refactor
• This is a test update
• This is a docs update
• This is a metadata update

For Bugs and Features; did you add new tests?

N/A

Motivation / Use-Case

There was a slight typo in #2116 that got unnoticed.

Breaking Changes

N/A

Additional Info

N/A

[codecov]

Codecov Report

Merging #2183 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2183   +/-   ##
=======================================
  Coverage   96.08%   96.08%           
=======================================
  Files          34       34           
  Lines        1227     1227           
  Branches      349      349           
=======================================
  Hits         1179     1179           
  Misses         47       47           
  Partials        1        1

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b5b9cb4...63c2e12. Read the comment docs.

[hiroppy]

No, we accept a string.

[hiroppy]

https://github.com/webpack/webpack-dev-server/blob/master/lib/utils/normalizeOptions.js#L20-L25

[hiroppy]

Why do you introduce this change?

We must add these cases.

string: transportMode: 'sockjs', 'ws'
object: transportMode.server, transportMode.client

And we've already had enough test cases.

This change breaks the above test cases.

[jamesgeorge007]

I assumed this from the diff (#2116) such that the change was specific to clientMode (transportMode.client)

[jamesgeorge007]

As seen from the test-case it is something specific to transportMode client:-
https://github.com/Loonride/webpack-dev-server/blob/aa17f7ca58eb3bd97a097f4901b58295acbe7334/test/e2e/TransportMode.test.js#L12-18

[alexander-akait]

@jamesblight what is problem here?

We support transportMode: 'ws and transportMode: { client: 'ws' , 'server': 'ws'}?

[jamesgeorge007]

@evilebottnawi as per what I see, the test was specific for transportMode client here
As evident from the diff, the respective test case was specific to options.clientMode (before #2116) which should be set to transportMode.client right 🤔

Instead, the entire transportMode object was being set.

[jamesgeorge007]

Hope I was able to convey the idea 🤔

[jamesgeorge007]

@jamesblight what is problem here?

wrong user mentioned 😅

[alexander-akait]

I think test is right here

[jamesgeorge007]

@evilebottnawi @hiroppy

options: {
  clientMode: 'sockjs'
}

was updated to be:-

options: {
  transportMode: 'sockjs'
}

As per what I infer, instead of having clientMode and serverMode #2116 introduced transportMode as:-

transportMode: {
  client: '',
  server: ''
}

Hence, options.transportMode.client should be an equivalent of options.clientMode right 🤔
Instead the respective case made use of just options.transportMode which made me confused 😕

[alexander-akait]

options.clientMode and options.serverMode were removed, now only transportMode option

[jamesgeorge007]

Even transportMode comprises of client and server entries right?

[alexander-akait]

@jamesgeorge007 yes, you can set transportMode: { client: myImplementation, server: 'ws} for example

[knagaitsev]

@jamesgeorge007

When we just had:

options: {
  clientMode: 'sockjs'
}

We were relying on the fact that the default serverMode was also sockjs, so that server and client could communicate. This is still the case, but in the future, the default mode will be changed to ws.

This is better, because it specifies both the client and server modes explicitly:

options: {
  transportMode: 'sockjs'
}

since it is equivalent to:

options: {
  transportMode: {
    client: 'sockjs',
    server: 'sockjs'
  }
}