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

Allow markbind serve to specify custom host #2382 #2395

Merged
merged 12 commits into from
Feb 17, 2024

Conversation

LamJiuFong
Copy link
Contributor

@LamJiuFong LamJiuFong commented Jan 28, 2024

What is the purpose of this pull request?

  • Documentation update
  • Bug fix
  • Feature addition or enhancement
  • Code maintenance
  • DevOps
  • Improve developer experience
  • Others, please explain:

Overview of changes:
Resolves #2382
Added -a option to the serve command

Anything you'd like to highlight/discuss:
Default host/address is 127.0.0.1. If the custom host specified by users is not working, run server on the default host

Testing instructions:
Run markbind serve -a <address>, eg. markbind serve -a 127.0.0.1

Proposed commit message: (wrap lines at 72 characters)
Allow markbind serve to specify custom host


Checklist: ☑️

  • Updated the documentation for feature additions and enhancements
  • Added tests for bug fixes or features
  • Linked all related issues
  • No unrelated changes

Reviewer checklist:

Indicate the SEMVER impact of the PR:

  • Major (when you make incompatible API changes)
  • Minor (when you add functionality in a backward compatible manner)
  • Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

  • To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

  • what was the old feature that was made obsolete
  • any replacement feature (if any), and
  • how the author should modify his website to migrate from the old feature to the replacement feature (if possible).

Copy link

codecov bot commented Jan 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5ca4704) 48.87% compared to head (1cedfbe) 48.87%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #2395   +/-   ##
=======================================
  Coverage   48.87%   48.87%           
=======================================
  Files         124      124           
  Lines        5238     5238           
  Branches     1109     1109           
=======================================
  Hits         2560     2560           
  Misses       2371     2371           
  Partials      307      307           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@yucheng11122017 yucheng11122017 left a comment

Choose a reason for hiding this comment

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

Hi @LamJiuFong thanks for the work!
One thing is I think it might be better to keep 127.0.0.1 as the default if the customised port isn't valid. What do you think?

} else if (e.code === 'EADDRNOTAVAIL') {
console.log('address(host) %s is not available. Trying another address'.yellow, host);
setTimeout(function() {
server.listen(port, '0.0.0.0');
Copy link
Contributor

Choose a reason for hiding this comment

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

I'll prefer to make 127.0.0.1 as the default address if the host is invalid. Because 0.0.0.0 has some special meaning and might accidentally expose it to the rest of the interner (see link).

@@ -56,6 +56,7 @@ program
.option('-p, --port <port>', 'port for server to listen on (Default is 8080)')
.option('-s, --site-config <file>', 'specify the site config file (default: site.json)')
.option('-d, --dev', 'development mode, enabling live & hot reload for frontend source files.')
.option('-a, --address <address>', 'specify the server address/host (Default is localhost')
Copy link
Contributor

@yucheng11122017 yucheng11122017 Jan 28, 2024

Choose a reason for hiding this comment

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

Forgot a closing bracket here 😔

Copy link
Contributor

@lhw-1 lhw-1 left a comment

Choose a reason for hiding this comment

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

The functional code should be good to go once you've addressed the comments - remember to update the relevant documentation and tests afterwards.

@@ -56,6 +56,7 @@ program
.option('-p, --port <port>', 'port for server to listen on (Default is 8080)')
.option('-s, --site-config <file>', 'specify the site config file (default: site.json)')
.option('-d, --dev', 'development mode, enabling live & hot reload for frontend source files.')
.option('-a, --address <address>', 'specify the server address/host (Default is localhost')
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of "localhost", let's specify the address as 127.0.0.1.

@@ -281,7 +281,13 @@ LiveServer.start = function(options) {
setTimeout(function() {
server.listen(0, host);
}, 1000);
} else {
} else if (e.code === 'EADDRNOTAVAIL') {
console.log('address(host) %s is not available. Trying another address'.yellow, host);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
console.log('address(host) %s is not available. Trying another address'.yellow, host);
console.log('%s is not available. Trying another address.'.yellow, host);

@LamJiuFong
Copy link
Contributor Author

Hi @yucheng11122017 @lhw-1, thank you for the suggestions. Initially I was thinking of setting 0.0.0.0 as the default host so that the users can run the server once there is any available host. However, I did overlook the safety issues of allowing this to happen. I think it's good to set '127.0.0.1' as the default host.

I will work on the descriptions too.

@itsyme
Copy link
Contributor

itsyme commented Feb 1, 2024

Do you think it is useful to add a warning for 0.0.0.0 specifically? I feel this way as our target audience are not only for technical people and could potentially unknowingly open up dangers to our non-technical users

@yucheng11122017
Copy link
Contributor

Do you think it is useful to add a warning for 0.0.0.0 specifically? I feel this way as our target audience are not only for technical people and could potentially unknowingly open up dangers to our non-technical users

Yeah this sounds good!

Copy link
Contributor

@yucheng11122017 yucheng11122017 left a comment

Choose a reason for hiding this comment

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

Hi @LamJiuFong thanks for the changes! Last thing is to add a warning as suggested by @itsyme when 0.0.0.0 is used. :)

@@ -158,7 +158,7 @@ function entryPoint(staticHandler, file) {
*/
LiveServer.start = function(options) {
options = options || {};
var host = options.host || '0.0.0.0';
var host = options.host !== undefined ? options.host : '127.0.0.1';
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
var host = options.host !== undefined ? options.host : '127.0.0.1';
var host = options.host || '127.0.0.1';

@LamJiuFong
Copy link
Contributor Author

Would like to seek advice on the latest commit, I display a warning and prompt the user to input "y" in the CLI to proceed with host 0.0.0.0 at their own risk. Is this a good idea to warn the users?

@@ -111,8 +137,9 @@ function serve(userSpecifiedRoot, options) {
const server = liveServer.start(serverConfig);
server.addListener('listening', () => {
const address = server.address();
const serveHost = address.address === '0.0.0.0' ? '127.0.0.1' : address.address;
const serveURL = `http://${serveHost}:${address.port}`;
const serveHost = address.address;
Copy link
Contributor

@itsyme itsyme Feb 10, 2024

Choose a reason for hiding this comment

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

What do you think about adding some validation to the user input host address?

I believe that this could be better for UX as

  • it checks the host address before building the pages (which could take some time)
  • it better handles the errors that are being thrown. Currently users will be exposed to errors like Error: getaddrinfo ENOTFOUND 127.0.300.1

I was thinking some sort of simple validation like checking if the input is an actual IP address and if any number in the address exceeds 255 could improve the user experience

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, good idea! I was thinking if we want to do this validation, we can actually just do the validations (including check if port is unavailable, check if host is being used etc) all at once before building the pages. Currently, all these validations are done after building the pages.

Since this PR is focusing on adding another small feature, I suggest we create a separate issue and pull request to specifically address this validation issue. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep I think a separate issue is fine as well! I believe there is some level of error handling for when the host is being used. From my experience if I specified a used host, the nearest unused hostname will be used, which allows the user to still serve the site. I think we can discuss about what needs to be validated once the issue is opened!

@@ -158,7 +158,7 @@ function entryPoint(staticHandler, file) {
*/
LiveServer.start = function(options) {
options = options || {};
var host = options.host || '0.0.0.0';
var host = options.host !== undefined ? options.host : '127.0.0.1';
var port = options.port !== undefined ? options.port : 8080; // 0 means random
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
var port = options.port !== undefined ? options.port : 8080; // 0 means random
var port = options.port ?? 8080; // 0 means random

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the suggestion, I wasn't aware of the difference between null and undefined in JS. Thank you for reminding.
I will also set line 161 to be
var host = options.host ?? '127.0.0.1';

@LamJiuFong
Copy link
Contributor Author

@yucheng11122017 @itsyme
I researched on the difference between the null coalescing operator ?? and the OR operator || and found out that the main difference between them is during the handling of falsy values like 0, empty string, empty list etc.
eg. 0 ?? 100 will return 0 but 0 || 100 will return 100.

I was thinking if we should use the ?? operator while handling missing host and port (line 161-162) so that if the user specifically enter 0, markbind will not default it to a specific host/port defined by us.
eg. using 0 || 127.0.0.1 will set the host to be 127.0.0.1 but 0 ?? 127.0.0.1 will set the host to be 0.0.0.0
I feel like the latter is more suitable. What do you think?

@kaixin-hc
Copy link
Contributor

Sounds good to me :) do make the change, I think this PR is almost there!

@itsyme
Copy link
Contributor

itsyme commented Feb 15, 2024

@yucheng11122017 @itsyme I researched on the difference between the null coalescing operator ?? and the OR operator || and found out that the main difference between them is during the handling of falsy values like 0, empty string, empty list etc. eg. 0 ?? 100 will return 0 but 0 || 100 will return 100.

I was thinking if we should use the ?? operator while handling missing host and port (line 161-162) so that if the user specifically enter 0, markbind will not default it to a specific host/port defined by us. eg. using 0 || 127.0.0.1 will set the host to be 127.0.0.1 but 0 ?? 127.0.0.1 will set the host to be 0.0.0.0 I feel like the latter is more suitable. What do you think?

I agree! My opinion is that we should use the nullish coalescing operator ?? in this case as this line should only be handling the responsibility of checking if any input is present from the user. For the other cases (e.g. 0, empty string, etc.), the responsibility should lie with the validation function instead. Wdyt @yucheng11122017 ?

@yucheng11122017
Copy link
Contributor

@yucheng11122017 @itsyme I researched on the difference between the null coalescing operator ?? and the OR operator || and found out that the main difference between them is during the handling of falsy values like 0, empty string, empty list etc. eg. 0 ?? 100 will return 0 but 0 || 100 will return 100.
I was thinking if we should use the ?? operator while handling missing host and port (line 161-162) so that if the user specifically enter 0, markbind will not default it to a specific host/port defined by us. eg. using 0 || 127.0.0.1 will set the host to be 127.0.0.1 but 0 ?? 127.0.0.1 will set the host to be 0.0.0.0 I feel like the latter is more suitable. What do you think?

I agree! My opinion is that we should use the nullish coalescing operator ?? in this case as this line should only be handling the responsibility of checking if any input is present from the user. For the other cases (e.g. 0, empty string, etc.), the responsibility should lie with the validation function instead. Wdyt @yucheng11122017 ?

Sounds good! Thanks for the research. Remember to write it in your knowledge base to get some credit HAHA

Copy link
Contributor

@yucheng11122017 yucheng11122017 left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks for the work @LamJiuFong

Copy link
Contributor

@itsyme itsyme left a comment

Choose a reason for hiding this comment

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

LGTM! Good work @LamJiuFong!

@kaixin-hc kaixin-hc merged commit 2647090 into MarkBind:master Feb 17, 2024
8 checks passed
@LamJiuFong LamJiuFong changed the title [Request for early review on functional code] Allow markbind serve to specify custom host #2382 Allow markbind serve to specify custom host #2382 Feb 19, 2024
@yucheng11122017 yucheng11122017 added the r.Minor Version resolver: increment by 0.1.0 label Feb 24, 2024
@yucheng11122017
Copy link
Contributor

yucheng11122017 commented Feb 24, 2024

@all-contributors please add @LamJiuFong for code

Copy link
Contributor

@yucheng11122017

I couldn't determine any contributions to add, did you specify any contributions?
Please make sure to use valid contribution names.

@yucheng11122017
Copy link
Contributor

@all-contributors please add @LamJiuFong for code

Copy link
Contributor

@yucheng11122017

I've put up a pull request to add @LamJiuFong! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
r.Minor Version resolver: increment by 0.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow markbind serve to specify custom host
5 participants