-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
feat/refactor(server): move socket handling into server.listen #2061
Conversation
Codecov Report
@@ Coverage Diff @@
## next #2061 +/- ##
==========================================
+ Coverage 96.05% 96.19% +0.14%
==========================================
Files 34 35 +1
Lines 1191 1236 +45
Branches 346 349 +3
==========================================
+ Hits 1144 1189 +45
Misses 46 46
Partials 1 1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job, just question
lib/Server.js
Outdated
userCallback(err); | ||
}); | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we refactor this on utils? Maybe multiple utils
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try
lib/Server.js
Outdated
socket, | ||
setupAndListenCallback, | ||
userCallback | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let rewrite this in style (pseudo code):
startUnixSocket(
this.listeningApp,
socket,
(error) => {
// Here logic for callback
}
);
Idea is not pass a lot of argument in util, just use closure for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@evilebottnawi I was passing in 2 callbacks because I didn't want options.onListening
to be called if an error occurred before the server starts listening. But maybe that is not important. If you think it is important, maybe we could have:
startUnixSocket(
this.listeningApp,
socket,
(error, startedListening) => {
if (startedListening) {
this.options.onListening(this);
}
// other functions that always get called, regardless of if server started listening
}
);
This pr has breaking changes so I think we should change from master to next. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, after investigation, looks like yes, it is breaking change, yes we should use next branch for this, anyway thanks for the PR
Should I switch it over to |
Yes |
@Loonride Could you rebase? |
298317b
to
580993b
Compare
@Loonride Do you need commits of the latest master before merging? If you need, I'll rebase the next branch from master. |
@hiroppy For this PR the latest master commits should not affect it |
After all, I'll rebase from the master to the next branch every time. master...next |
b5c454d
to
148dfd5
Compare
580993b
to
166ef18
Compare
166ef18
to
7779cfb
Compare
lib/utils/startUnixSocket.js
Outdated
}); | ||
}; | ||
|
||
fs.access(socket, fs.constants.F_OK, (e) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to use a callback. Just use promisify
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks!
setTimeout(() => { | ||
expect(userCallback).toBeCalledTimes(1); | ||
done(); | ||
}, 10000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this value is big but do we need 10000?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 3000 should be enough.
Need to rebase. |
0adc304
to
8577191
Compare
setupCallback(); | ||
userCallback(err); | ||
onListeningCallback(); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should refactor this in future, looks very misleading
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really those 3 functions can all be in fullCallback
, since they are only called by fullCallback
. Originally I was doing some other things with these individual functions to avoid a few breaking changes and stay organized, but do you think just putting all their functionality in that one callback will be cleaner?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Loonride i think we should allow userCallback
to be async, also ehre good questions should userCallback
will be called before or after onListeningCallback
, potentially user callback should be called after all operation, it is allow do something with server (or not with server) when webpack-dev-server starts, for example for other web server, (for example if you use php project, you should use this callback to run php dev server)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we should allow userCallback to be async
Maybe we should do this in a separate PR?
potentially user callback should be called after all operation
So this is a good order the way I have above, because userCallback
is after setupCallback
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should do this in a separate PR?
Yes, just thoughts
So this is a good order the way I have above, because userCallback is after setupCallback, right?
oh, it is interesting, i think userCallback
should be after all callbacks, because i want to get socket information after starts server
There was a problem hiding this comment.
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 about this too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to change onListening(err, server)
. In fact, this format is correct as Node.js theory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 agree
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So can we get this merged, and then I'll do 2 PRs:
- async
userCallback
onListening(err, server)
But @evilebottnawi can you clarify the async one? A user can already do this without problems:
server.listen(port, host, async (err) => {
await something();
// ...
});
And I think there are no things before userCallback
that are asynchronous. Maybe you mean we should do:
setupCallback();
await userCallback(err);
onListeningCallback();
But the only thing this would do is delay onListeningCallback
until a potentially async userCallback
is complete.
Is this what you meant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But @evilebottnawi can you clarify the async one? A user can already do this without problems:
server.listen(port, host, async (err) => {
await something();
// ...
});
Yep, but it is require to create own util for running webpack-dev-server, in some cases it is unnecessary, because you want run one simple task when webpack-dev-server started
But the only thing this would do is delay onListeningCallback until a potentially async userCallback is complete.
Is this what you meant?
It is expected and can be used for some features
Good job! |
For Bugs and Features; did you add new tests?
Yes
Motivation / Use-Case
This is the
socket
option handling portion of: #2028. The goal is to move socket handling out of the CLI and into the APIlisten
method.Breaking Changes
API users will now get different behavior when they put a socket path in place of
port
in theserver.listen(port, hostname, fn)
method.Additional Info
This should be merged before I start work on the
findPort
portion of #2028