Skip to content

Update package-lock.json; Fix dep vulnerabilities. #163

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

Closed
wants to merge 1 commit into from

Conversation

BigBlueHat
Copy link
Member

No description provided.

@iherman
Copy link
Member

iherman commented Jan 2, 2024

I wonder where these dependencies come from... are they related to the common js scripts that are used to generate the final version of the spec (via respec)?

How come the only file that is updated is the package-lock.json file (a file that a lambda user is not supposed to modify...)

I am always vary of these dependency checks; alas!, new versions of npm packages (for example) are not always backward compatible, so it may require more than just an update of some json files.

@BigBlueHat
Copy link
Member Author

@iherman there's ancient debate about the value of keeping package-lock.json in version control. It's mainly for pinning more specific (minor) versions of the more general (major/wild-card) versions in package.json. If/when keeping that minor version recorded and/or updated isn't worth the overhead (vs. trusting the latest findings based on package.json), then deleting it--rather than updating it--would have the same effect as this update has done.

At this point, I'd suggest removing package-lock.json would probably be a better choice for this particular project--and would silence the fearful robots who've been reading that file "too" carefully. 😉

@iherman
Copy link
Member

iherman commented Jan 2, 2024

@iherman there's ancient debate about the value of keeping package-lock.json in version control. It's mainly for pinning more specific (minor) versions of the more general (major/wild-card) versions in package.json. If/when keeping that minor version recorded and/or updated isn't worth the overhead (vs. trusting the latest findings based on package.json), then deleting it--rather than updating it--would have the same effect as this update has done.

At this point, I'd suggest removing package-lock.json would probably be a better choice for this particular project--and would silence the fearful robots who've been reading that file "too" carefully. 😉

@BigBlueHat removing it is fine with me. Except that... I do not really "own" this repo anymore, not being the staff contact of this WG. I think the current staff contact or the WG chair should take action...

@BigBlueHat
Copy link
Member Author

@BigBlueHat well. Since I happen to be the chair... 😁 I'll get a different PR up shortly. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants