-
Notifications
You must be signed in to change notification settings - Fork 54
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
release 2.0.0 #95
release 2.0.0 #95
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we update this as well:
node-xml-encryption/package.json
Line 35 in 291f3f1
"node": ">=8" |
nit: Also do we still want to keep the package-lock file since this is a library and considering it was removed in the previous PR? |
Also updates package lock file to version 2; backwards compatible to version 1
d3f577e
to
77ccf3b
Compare
@gkwang was the package-lock file ever removed? Based on it's history here: https://github.com/auth0/node-xml-encryption/commits/master/package-lock.json, it's been around since Jan 2020. |
My 2 cents since I'm around ;) having or not a package lock is a recurring debate in npm modules. It can still make sense to lock the dependencies of libraries, if only for the dev ones, as it makes CI build more reproducible (ie the build won't start failing when there is no change in the repository). The lock will have no impact on the users of the library as it's not included in the package, and they should do their own locking |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I think we can leave the package-lock around to make some of our tools happy.
Description