Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encapsulate sockjs, introduce ws and build base for users to make own server implementation #1904

Merged
merged 7 commits into from May 28, 2019

Conversation

knagaitsev
Copy link
Collaborator

  • 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?

No

Motivation / Use-Case

Refactored to encapsulate sockjs better so that it is easier to implement ws or other user defined server implementations.

Issue: #1860

Breaking Changes

I am unsure if moving sockjs out breaks this: https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L41

Otherwise there should be no breaking changes.

Additional Info

Tests were failing locally, I think it is related to a snapshots though: #1889

@codecov
Copy link

codecov bot commented May 17, 2019

Codecov Report

Merging #1904 into master will decrease coverage by 1.22%.
The diff coverage is 60%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1904      +/-   ##
==========================================
- Coverage      88%   86.77%   -1.23%     
==========================================
  Files          16       20       +4     
  Lines         817      862      +45     
  Branches      260      265       +5     
==========================================
+ Hits          719      748      +29     
- Misses         84       99      +15     
- Partials       14       15       +1
Impacted Files Coverage Δ
lib/servers/baseServer.js 100% <100%> (ø)
lib/servers/BaseServer.js 100% <100%> (ø)
lib/servers/SockJSServer.js 55.55% <55.55%> (ø)
lib/servers/sockjsServer.js 55.55% <55.55%> (ø)
lib/Server.js 87.27% <60%> (+1.31%) ⬆️

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 87cfaa7...bee6f83. Read the comment docs.

lib/Server.js Outdated
@@ -32,6 +31,7 @@ const createDomain = require('./utils/createDomain');
const runBonjour = require('./utils/runBonjour');
const routes = require('./utils/routes');
const schema = require('./options.json');
const SockjsServer = require('./utils/server/sockjsServer');

// Workaround for sockjs@~0.3.19
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move workaround to sockjsServer

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

lib/Server.js Outdated

socket.on('connection', (connection) => {
socket.onConnection((connection) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better use this.sockerServer everywhere

onConnection(f) {
this.socket.on('connection', f);
}
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move this to lib/servers/sockjsServer.js, it is not util

package.json Outdated
@@ -62,6 +62,7 @@
"url": "^0.11.0",
"webpack-dev-middleware": "^3.7.0",
"webpack-log": "^2.0.0",
"ws": "^6.2.1",
"yargs": "12.0.5"
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need this right now, it is increase package size

lib/Server.js Outdated
@@ -32,6 +31,7 @@ const createDomain = require('./utils/createDomain');
const runBonjour = require('./utils/runBonjour');
const routes = require('./utils/routes');
const schema = require('./options.json');
const SockjsServer = require('./utils/server/sockjsServer');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rename sockjsServer to SockJSServer because it is class

lib/Server.js Outdated
error: this.log.error.bind(this),
debug: this.log.debug.bind(this),
server: this.listeningApp,
path: this.sockPath,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better always pass all options (this.options)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@evilebottnawi Are you suggesting, in addition to what is already there, options: this.options? Because this.listeningApp is not part of the options, along with the error, debug callbacks.

Users may be creating server implementations of their own, so they would be interacting with the options passed in. Do you think it's a good idea to expose all the options to the user?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Loonride

Do you think it's a good idea to expose all the options to the user?

Yes, we because behavior can be changed based on options (not only) in theory.

Let's do it like:
new SockJSServer(this);

Custom implementation should have access to compiler, application, server, options and devServer.

Also it is not available for developers right now, so we can change this in future.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some notes, anyway good idea and good solution

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One note

@alexander-akait
Copy link
Member

/cc @hiroppy

@@ -0,0 +1,64 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file name should be changed from sockjsServer.js to SockJSServer.

@@ -0,0 +1,8 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file name should be changed from wsServer.js to WsServer.

@@ -0,0 +1,5 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file name should be changed from baseServer.js to BaseServer.


// ws server implementation under construction
// will need changes in the client as well to function
module.exports = class WSServer extends BaseServer {};
module.exports = class WsServer extends BaseServer {};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/cc @hiroppy What do you think is better:

  • WebsocketServer
  • WSServer
  • WsServer

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like WebsocketServer. For example, the plugin name of wasm(WebAssemblyPlugin) which webpack has is not omitted. But this example is webpack, not webpack-dev-server. In any case, I think that it is easier to understand if it is not omitted.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 let's use WebsocketServer

/cc @Loonride

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, one questions

/cc @hiroppy

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/cc @hiroppy

@knagaitsev
Copy link
Collaborator Author

@evilebottnawi, @hulkish says just to continue work in this pr, are you fine with that or do you want to get the base changes merged first?

@hiroppy
Copy link
Member

hiroppy commented May 27, 2019

Please don't continue to work in this pr. Because don't give PR more than one content, as it will be difficult to review.

@hulkish
Copy link

hulkish commented May 27, 2019

@hiroppy

Plese don't continue to work in this pr. Because don't give PR more than one content, as it will be difficult to review.

I disagree, this is all part of the same gsoc effort. What things do u think deviate enough to be considered separate?

@hulkish
Copy link

hulkish commented May 27, 2019

@Loonride please add tests which validate support for clientMode & serverMode (as we discussed on slack)

@hiroppy
Copy link
Member

hiroppy commented May 27, 2019

We have next branch for the major version. If this pr is changed to next branch, this problem will be resolved because it is not used now? Or do you want a branch dedicated to GSoC? I oppose continuing development on this branch. You should create a dedicated branch and submit PR there. Continued development on this branch will increase the cost of the reviewer.

@hiroppy
Copy link
Member

hiroppy commented May 27, 2019

If you want to need gsoc branch, I'll create it.

@hulkish
Copy link

hulkish commented May 27, 2019

@hiroppy How about:

  • create next branch, if not exists already.
  • point the target branch for this pr to next
  • merge this pr to next once code review passes
  • go from there?

@knagaitsev
Copy link
Collaborator Author

I like the idea of having gsoc / next branch. No chance of adding a breaking change in master as I implement things, and also I will be more efficient if I can do more work per PR.

@hulkish
Copy link

hulkish commented May 27, 2019

@Loonride i think that may be beside the point - your code will be merged once stable (with tests)

then, the next branch will act as the living alpha or beta, until the collection of changes have all made it in and are stable

@hiroppy
Copy link
Member

hiroppy commented May 27, 2019

this is all part of the same gsoc effort.

I agree with this idea. I think it is a good idea to put them into one branch so that you can easily visualize the results.

I like the idea of creating gsoc branch. because maybe I'll use next branch for webpack5. Also, don't forget that you need to periodically rebase from master branch.

@knagaitsev
Copy link
Collaborator Author

Should I add tests on the new files to pass codecov?

@alexander-akait alexander-akait merged commit d7aaef6 into webpack:master May 28, 2019
@knagaitsev knagaitsev added gsoc Google Summer of Code scope: ws(s) labels Aug 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gsoc Google Summer of Code scope: ws(s)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants