Check-in lib & esm folders?

[BurtHarris]

Normally I don't check-in build products, but as I think things over I think this long-held practice has a lot to do with the limitations of previous version control systems and build tools. Given how git & TypeScript behave, is this worth reexamination?

Potential benefits 1) It becomes possible to take a dependency on a specific commit by using a GitHub reference in package.json. This won't work if we just check in sources. 2) It is easy to compare versions of generated code online, see the impact of things like build tool upgrades. 3) CI scripts can be updated to warn if contributor's tools versions don't generate code matching tools on CI system. We still have the CI scripts run the transpilers, but then check if the working tree is dirty.

Fixes for old problems

• Binary files shouldn't be checked in: our build outputs aren't binary.
• Complications to build process: since git doesn't require explicit checkout, this shouldn't be a problem

[jayphelps]

I'm pretty hesitant because I've had negative experiences in the past with rebase issues, PRs including changes they shouldn't, people coming here and downloading these files even though they may be not be stable/released, and above all I don't want to increase the possibility of additional support requests from people taking advantage of this in some way. If this was a big project with lots of active contributors I think it'd be ok but historically was just me; of course, until you came along 😄

tl;dr I'm not convinced the potential headaches are worth the very small (if any) number of people who would take advantage of it for legitimate purposes and not mistakenly.

BUT, as always, you're welcome to convince me!

[BurtHarris]

Thanks. That's OK, it was an RFC, not worth pushing hard on at this time..