Fix Failing GitHub Actions Frontend Vulnerability Check (Bump node-ip 1.1.8 -> 1.1.9)

[Matthew-Grayson]

🗣 Description

💭 Motivation and context

Closes issue #2553 Fix frontend vulnerability and address associated failing GitHub Actions check.

🧪 Testing

✅ Pre-approval checklist

• [x] This PR has an informative and human-readable title.
• [x] Changes are limited to a single goal - eschew scope creep!
• [x] All future TODOs are captured in issues, which are referenced in code comments.
• [x] All relevant type-of-change labels have been added.
• [x] I have read the CONTRIBUTING document.
• [x] These code changes follow cisagov code standards.
• [x] All relevant repo and/or project documentation has been updated to reflect the changes in this PR.
• [x] Tests have been added and/or modified to cover the changes in this PR.
• [x] All new and existing tests pass.

✅ Pre-merge checklist

• [ ] Revert dependencies to default branches.
• [ ] Finalize version.

✅ Post-merge checklist

• [ ] Create a release.

[schmelz21]

@Matthew-Grayson, @nickviola, @cduhn17 - When rerunning checks yesterday evening, it looks like Github has reinstated the vulnerability. Can we look at updating to v2.0.1. and do some tests. There is indications that this release is passing in some of the comments in the 'node-ip' repo.

[schmelz21]

noting dependabot fix - same code change. https://github.com/cisagov/crossfeed/pull/2560

[schmelz21]

Wouldn't we need to update the package.json instead of the package-lock.json? There could be something I'm missing in how we want to deploy, but that should be the normal process, correct?

@nickviola - Per our conversation can we satisfy this comment and approve?

[nickviola]

Wouldn't we need to update the package.json instead of the package-lock.json? There could be something I'm missing in how we want to deploy, but that should be the normal process, correct?

@nickviola - Per our conversation can we satisfy this comment and approve?

If just updating package-lock.json doesn't cause any issues, thats good with me. I was just thinking that we needed to update in package.json regardless of whatever version we decide. If someone can verify, all good on my end.

[schmelz21]

Wouldn't we need to update the package.json instead of the package-lock.json? There could be something I'm missing in how we want to deploy, but that should be the normal process, correct?

@nickviola - Per our conversation can we satisfy this comment and approve?

If just updating package-lock.json doesn't cause any issues, thats good with me. I was just thinking that we needed to update in package.json regardless of whatever version we decide. If someone can verify, all good on my end. [ ]

@nickviola - Note the file change from dependabot. (https://github.com/cisagov/crossfeed/pull/2560/files). I figure we use this PR as it contains history and tracked against the project. Also, some additional scope around your question. see the "Answer" . https://stackoverflow.com/questions/58372839/whats-difference-between-package-lock-json-and-package-json-when-is-package-jso

[nickviola]

Wouldn't we need to update the package.json instead of the package-lock.json? There could be something I'm missing in how we want to deploy, but that should be the normal process, correct?

@nickviola - Per our conversation can we satisfy this comment and approve?

If just updating package-lock.json doesn't cause any issues, thats good with me. I was just thinking that we needed to update in package.json regardless of whatever version we decide. If someone can verify, all good on my end. [ ]

@nickviola - Note the file change from dependabot. (https://github.com/cisagov/crossfeed/pull/2560/files). I figure we use this PR as it contains history and tracked against the project. Also, some additional scope around your question. see the "Answer" . https://stackoverflow.com/questions/58372839/whats-difference-between-package-lock-json-and-package-json-when-is-package-jso

Sounds good. I'll resolve the requested changes.