Either commit package-lock.json, or gitignore it

[alexweissman]

Right now, build/package-lock.json is created for the first time when you run build-assets or bake. We should decide if we want to commit it to UF (thus locking devs at the same versions of the packages that we used in the release), or gitignore it.

I'd argue the same goes for composer.lock.

[lcharette]

@Silic0nS0ldier This file is annoying me. What should we do with it ?

[Silic0nS0ldier]

From a security perspective, I vote keep it. GitHub routinely runs a security audit on files like this, and if we remove it we risk not finding out about a known vulnerability. Vulnerable dependencies could inject code that is run client side (or even when the project is deployed) permitting session hijacking attacks and at worse server takeover. Node isn't the most locked down system by default, so keeping tabs on vulnerabilities that affect us is important.

My opinion regarding the file might change if alternatives turn up. (an alternative will be needed if user extensions get hooked up in the future)

[lcharette]

Above the security audit, thing is, just like composer.lock, that file will change when dev add their own dependencies. Since a dev shouldn't commit his code as part of the UF main repo, that file will stay in a modified state forever, which cause problem when switching branch or tags as I'm experiencing right now.

One of composer.lock goal is to install the same same dependencies version as the staging env when deploying to a live site using composer install. Only the update command will update the lock file with newer version. This is something we don't actually use in UF, and for the package lock file, this is not used at all, since the Bakery command always seams to run the "update" command.

Thing is, if it doesn't bring any benefit right now, other than the security audit thing, I vote we gitignore it. But at the same time, I vote we do look for a way for a dev to be able to commit this file with all their project dependencies somehow. Probably something we can work out along #830.

[Silic0nS0ldier]

Considering how UserFrosting is used, I'm thinking ignoring it is the better choice. Will just annoy users with merge conflicts, etc. Come V5 this shouldn't be an issue (🤞).

[lcharette]

https://media.giphy.com/media/VLoN2iW8ii3wA/giphy.gif

[Silic0nS0ldier]

https://media.giphy.com/media/5YO4km322zuNy/giphy.gif
(it is done)