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

Add a lock file #1940

Open
god464 opened this issue Sep 21, 2023 · 3 comments
Open

Add a lock file #1940

god464 opened this issue Sep 21, 2023 · 3 comments

Comments

@god464
Copy link

god464 commented Sep 21, 2023

What version of this package are you using?
V17.1.0
What problem do you want to solve?
As I said on discord. I want to help add Standardjs to Nixpkgs. But according to this issue, we need to add the lock file on upstream. And adding lock files is helpful for any future development (see the discord link for details).
What do you think is the correct solution to this problem?
Per title.
Are you willing to submit a pull request to implement this change?
Yes if I can.

@god464 god464 changed the title Add alock file Add a lock file Sep 25, 2023
@LinusU
Copy link
Member

LinusU commented Sep 30, 2023

Hmm, I'm not sure how all processes should look around this.

Currently, as distributed via Npm, the newest semver compatible versions of every dependency is used whenever a user installs or updates the package. This makes it so that any security fixes or other patches are automatically applied without us having to do anything.

If we add a lock file, do we need to make a new release anytime a security fix is released in any downstream packages? This feels like we are adding both work and responsibility on us in order to only support the Nix distribution 🤔

@voxpelli
Copy link
Member

I’m largely 👎 on this. It’s nice to be able to support as many places as possible, but a lockfile would have to be maintained as well as @LinusU says

@wesleytodd
Copy link

wesleytodd commented Nov 21, 2023

The key issue around libraries using lockfiles is that we need to ensure the final build before publish blows away the entire lockfile. If you don't do this then the consumers could get newer transitive dependencies than the tests were run with, possibly breaking immediately when they update. There is currently not a lot of good tooling around that workflow, but I would be interested in building it if we wanted to use it here. There are some details to work out though since we don't have fully automated publish from CI.

EDIT: I guess I should have added, without the proper tooling I am also 👎 on adding a lockfile.

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

No branches or pull requests

5 participants
@voxpelli @LinusU @wesleytodd @god464 and others