You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past we had decided that lock file should NOT be committed directly to this repo and thus force devs who are bootstrapping a new project to generate them when they get started.
Let's discuss here this approach and make a decision on where we stand on it. Currently the backend does NOT have a lock file committed, but the FE does as of mid-2024.
The text was updated successfully, but these errors were encountered:
I think if we include it, a lot of projects will get bootstrapped where that lock file might not get updated for a while.
I could see a number of possible issues/risks with this:
Could things work day one, but then fail the second a new lock file is generated?
If we start getting more outside contributions to this project, could someone sneak a nefarious library in via the lock file? I think it's unlikely anyone would code review changes to those files.
In the past we had decided that lock file should NOT be committed directly to this repo and thus force devs who are bootstrapping a new project to generate them when they get started.
Let's discuss here this approach and make a decision on where we stand on it. Currently the backend does NOT have a lock file committed, but the FE does as of mid-2024.
The text was updated successfully, but these errors were encountered: