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

fix(deps): upgrade wait-port to v1 and listen on correct address for framework #5094

Merged
merged 3 commits into from
Sep 30, 2022

Conversation

danez
Copy link
Contributor

@danez danez commented Sep 28, 2022

🎉 Thanks for submitting a pull request! 🎉

Summary

Updates wait-port to v1 which now tries both IPv6 and IPv4 and also reports where it found the open port. The proxy will then proxy to the correct address.

This should once and for all solve the IPv4 vs IPv6 problem with node 17+

Fixes #4845

Maybe helps with #3735 and #4942


For us to review and ship your PR efficiently, please perform the following steps:

  • Open a bug/issue before writing your code 🧑‍💻. This ensures we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or something that`s on fire 🔥 (e.g. incident related), you can skip this step.
  • Read the contribution guidelines 📖. This ensures your code follows our style guide and
    passes our tests.
  • Update or add tests (if any source code was changed or added) 🧪
  • Update or add documentation (if features were changed or added) 📝
  • Make sure the status checks below are successful ✅

A picture of a cute animal (not mandatory, but encouraged)

@danez danez added the type: bug code to address defects in shipped code label Sep 28, 2022
@danez danez changed the title fix(deps): upgrade wait-port to v1 and listen on correct address for … fix(deps): upgrade wait-port to v1 and listen on correct address for framework Sep 28, 2022
@github-actions
Copy link

github-actions bot commented Sep 28, 2022

📊 Benchmark results

Package size: 223 MB

^  223 MB 
│   ┌──┐  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
└───┴──┴──>
     T    
Legend
  • T (current commit): 223 MB

@danez danez force-pushed the frameworkport-node18 branch from 1f53595 to 27eef3a Compare September 28, 2022 08:55
@danez danez marked this pull request as ready for review September 28, 2022 10:00
@danez danez requested a review from lukasholzer September 29, 2022 07:38
Copy link
Member

@eduardoboucas eduardoboucas left a comment

Choose a reason for hiding this comment

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

Nice! I left minor comments, mostly cosmetic.

@@ -178,18 +178,25 @@ const runCommand = (command, env = {}, spinner = null) => {
return commandProcess
}

/**
* @typedef StartReturnObject
* @property {4 | 6 | undefined=} ipVersion The version the open port was found on
Copy link
Member

Choose a reason for hiding this comment

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

I'm assuming this is a typo?

Suggested change
* @property {4 | 6 | undefined=} ipVersion The version the open port was found on
* @property {4 | 6 | undefined} ipVersion The version the open port was found on

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No the equal sign marks the field as optional

/**
* Start a static server if the `useStaticServer` is provided or a framework specific server
* @param {object} config
* @param {Partial<import('../../utils/types').ServerSettings>} config.settings
* @returns {Promise<void>}
* @returns {Promise<StartReturnObject>}
Copy link
Member

Choose a reason for hiding this comment

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

The return value is always an empty object, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Either empty or has the property ipVersion

@@ -221,6 +228,8 @@ const startFrameworkServer = async function ({ settings }) {
log(NETLIFYDEVERR, `Please make sure your framework server is running on port ${settings.frameworkPort}`)
exit(1)
}

return { ipVersion: port?.ipVersion }
Copy link
Member

Choose a reason for hiding this comment

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

oooh, I like that we can finally use optional chaining in the CLI!

Copy link
Collaborator

Choose a reason for hiding this comment

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

yea because we dropped node 12 🥳

const devCommand = () => startFrameworkServer({ settings })
const devCommand = async () => {
const { ipVersion } = await startFrameworkServer({ settings })
// eslint-disable-next-line no-magic-numbers
Copy link
Member

Choose a reason for hiding this comment

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

nit: I would actually create a constant for this.

Copy link
Collaborator

Choose a reason for hiding this comment

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

IMHO I think it's easier to understand in the context of 6 ? '::1' : '127.0.0.1'

But I think it's personal preference just my 2 cents

@danez danez merged commit 3f1913a into main Sep 30, 2022
@danez danez deleted the frameworkport-node18 branch September 30, 2022 08:54
Comment on lines -207 to +214
host: '127.0.0.1',
host: 'localhost',

Choose a reason for hiding this comment

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

@danez @eduardoboucas this has caused a regressions for one of our own CI pipelines https://netlify.slack.com/archives/CPJQSPQE4/p1665509398672569

Could we use settings.frameworkHost here to solve this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug code to address defects in shipped code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

After upgrade to 10.11.1 netlify dev hangs on "waiting for port"
4 participants