Closed yimmyj closed 1 year ago
Thanks for contributing! If you've made changes to the API's functionality, please make sure to bump the package version—see this guide to semantic versioning for details—and document those changes as appropriate.
Why are we gitignoring yarn.lock
in this PR? I think we should keep it in because it defines the exact versions that all are our dependencies should be at that we know are guaranteed to work. If we remove it, then yarn
in CI will create its own Lockfile from the package.json
versions that may generate different versions from expected. For example, @sendgrid/mail here is defined as ^7.4.4
, which means that any version that is 7.x.x
is acceptable. For the current yarn.lock
committed to master, that version is 7.6.1, but removing the yarn.lock and having it regenerated might produce a different version that could introduce bugs or breaking changes.
Ideally we pin all of our dependencies' versions at versions that we know are working, but as you might be able to imagine that is a pretty tedious process. So our remedy in the meanwhile is to persist the Lockfile to ensure versions across deploys stay consistent
I changed the "create" function for creating an event in EventService.ts. I added "await" before the method isUnusedAttendanceCode. Prior to my change, isUnusedAttendanceCode would be a promise instead of the actual boolean value (false), and the if condition for throwing the human-readable error could never be reached. Closes #352.