Remove and ignore yarn.lock

[mturley]

As discussed in an email thread with @Fryguy and @himdel, we should no longer track yarn.lock on git master.

[codeclimate]

The PR diff size of 7056 lines exceeds the maximum allowed for the inline comments feature.

[miq-bot]

Checked commit mturley@5a9ab94 with ruby 2.5.5, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
0 files checked, 0 offenses detected
Everything looks fine. 🏆

[Fryguy]

Going to merge and see how this goes...we can always revert or rebuild it if necessary

[mturley]

@Fryguy @himdel we're starting to see in PRs after this one that CI tests are failing just because of changes in our dependencies that are being pulled in because we don't have those versions locked anymore. I'm trying to track them all down and use specific version numbers in package.json for those packages instead of the ^ syntax, but it worries me that our CI can break without any change in our own code (tests fail on master right now). I wonder if we should put yarn.lock back and deal with those CVE warnings another way? I'll see what I can do with pinning versions.

[himdel]

@mturley I think we just need fix the dependencies in package.json to no longer accept versions with breaking changes, I'd assume ~ instead of ^ should do the trick, shouldn't it?

[mturley]

That sounds like a good idea, thanks @himdel. I forgot about the ~ operator. Do you think I should go ahead and change all our dependencies to use it now, or wait until we run into any other issues?

[himdel]

Up to you really.. it's always a balancing act between npm audit complaining about too old versions and new versions breaking stuff :), ~ definitely helps, but isn't 100% either.

So, if you'd rather run npm audit regularly (since depedabot won't do it without the lockfile),
and update because you have to, you can get more control that way.

OTOH changing to ~ now means you can mostly stop thinking about it, at least until something new breaks :).

[mturley]

I think for now I'll wait for something new to break, but I'll keep this on my mind. Thanks @himdel !