Remove lockfile, add to gitignore, and add npmrc preventing its generation

[weswigham]

Our lockfile is unused in all our CI processes. It also shouldn't be used, since our goal is to always be built with our latest dependencies (hence the latest tag on most of our dependencies). Lockfiles are more for reproducible builds using npm ci for end-user applications. It's presence frequently adds noise to PRs (where updates to it are frequently included by chance) and its presence is currently flagging the repo with a vulnerability warning because it contains a hard reference to an exact package version with a vulnerability, because it is not actually purposely maintained.

[moll]

I'm puzzled. How is one supposed to build an older version of TypeScript if one doesn't know which dependencies it worked with? Stuff changes in backwards incompatible ways all the time and having no record of working dependencies makes it impossible to build an older version. Occasionally it obviously impedes even building the latest version. I argue you should at least lock down major versions and hope for the best that everyone follows semver.

[weswigham]

How is one supposed to build an older version of TypeScript if one doesn't know which dependencies it worked with?

Roll the malfunctioning deps backwards until they work, mostly. As I originally said in the PR OP: We only build against latest because we want to ensure constant up-to-date-ness with our tooling deps (some depend on our own nightly!), and we deleted the lockfile because we didn't use it and never installed from it - in fact, libraries (like us) should pretty much never use it (you'd use exact dependency versions optionally with a shrinkwrap if you need to fix your versions instead). Since we don't have a consistently updated lockfile, there is no historical record of what we were able to be built with, but in reality, there's only a handful of things that you'd ever need to roll back, usually - @types/node, gulp, and mocha. Pretty much nothing else has ever broken us with an update. Also, since we're talking temporally here, it's not too bad to query npm for the versions of the malfunctioning packages which had been published at the time of the commit in question, if you wanted less guesswork involved.