fix: escape IPv6 address in Node 17 #2334
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2334 +/- ##
==========================================
- Coverage 99.88% 99.82% -0.06%
==========================================
Files 32 32
Lines 1699 1702 +3
==========================================
+ Hits 1697 1699 +2
- Misses 2 3 +1
Continue to review full report at Codecov.
|
|
Hmm perhaps we should just change web-ext/src/extension-runners/chromium.js Line 139 in 96d40a1 |
There was a problem hiding this comment.
@eight04 thanks for filing and investigating #2331 ❤️
If I'm reading #2331 correctly, to fully fix the web-ext run -t chromium on nodejs 17 does require that the chrome-launcher issue has to be fixed as well, is that right?
If you have already filed a github issue in the chrome-launcher repo, would you mind to mention it in the issue and pull request description? (just so that we can track it the upstream issue and adjust our plans with the web-ext side of the issue accordingly).
Follows an initial round of review comments.
Would you mind to also remove the package-lock.json changes? (to initialize the repo without making npm to regenerate this lock file into its v2 format you can use npm ci instead of npm install).
| @@ -424,3 +424,10 @@ export class ChromiumExtensionRunner { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| export function escapeIPv6(address: string): string { | |||
| if (/^([a-f0-9:]+:+)+[a-f0-9]+$/.test(address)) { | |||
There was a problem hiding this comment.
it looks that nodejs does provide a net.isIPv6 method since nodejs 0.3.0:
Personally I think I would prefer using that nodejs API method here to detect if the string is an IPv6 address instead of a regular expression.
Given that this method is also exported, we may cover it with a simple unit test (and that should also make codecov happy).
There was a problem hiding this comment.
Another testing-related detail: along with covering the escapeIPV6 method with a unit test, we should also double-check how we may also want to assert in tests defined in test.chromium.js test file that escapeIPV6 has been called internally by the ChromiumExtensionRunner class, and so we would need it to be wrapper or replaced in the test with a sinon spy.
To make our life easier, we may actually see if we can just add it as an optional parameter of the createReloadManagerExtension method, set to the esacpeIPV6 function here by default, then in the test we may call this method directly along with passing to it the sinon.spy, and finally assert that we got the expected result and that the sinon.spy has been called the expected number of times and with the expected parameters.
| @@ -126,7 +127,7 @@ describe('util/extension-runners/chromium', async () => { | |||
|
|
|||
| // $FlowIgnore: allow to call addess even wss property can be undefined. | |||
| const wssInfo = runnerInstance.wss.address(); | |||
| const wsURL = `ws://${wssInfo.address}:${wssInfo.port}`; | |||
| const wsURL = `ws://${escapeIPv6(wssInfo.address)}:${wssInfo.port}`; | |||
There was a problem hiding this comment.
Nit, to avoid having to recall to do this escaping manually, it seems to me that it may be reasonable to create a method that return a ws url given address and port, how that sounds?
| @@ -17,7 +17,7 @@ exports.flowCheck = () => { | |||
| }; | |||
|
|
|||
| exports.flowStatus = () => { | |||
| const res = spawnSync('flow', ['status'], {stdio: 'inherit'}); | |||
| const res = spawnSync('flow', ['status'], {stdio: 'inherit', shell: true}); | |||
There was a problem hiding this comment.
I'm guessing that adding shell: true here is making this script able to run flow on Windows 10 (and it was not working without it), is that right?
Would you mind to split this out in a separate PR as a single commit with the following commit message (following the conventional changelog format)?
`"chore: Fixed issue with running flow checks on Windows"
we could merge that part right away.
@eight04 eh, I completely missed to notice this comment, and I just jumped to look to the PR first. That seems to be another option that we can consider. Given that we still need the dependencies that are breaking due to this nodejs 17 breaking change, it looks that we may need to track some issues filed upstream and some in web-ext itself to make web-ext to fully support nodejs 17, I filed #2337 as a meta bug to tracking the issues related to nodejs 17 compatibility issues. Out of curiosity: have you tried if |
Yes this works. Chrome can be connected correctly and I don't need to specify I'll close this and file two new PRs for flow-check on Windows and to replace localhost with ipv4 which should be simpler. |
Part of #2331.