2881961859
* feat: add custom calendar reminder for Google Calendar events Allows users to set default reminder notifications (10, 30, or 60 minutes) for events created via Cal.com bookings in Google Calendar. This addresses the issue where Google Calendar's default reminders don't apply to API-created events. - Add customCalendarReminder field to DestinationCalendar model - Create reminder selector UI in destination calendar settings - Update GoogleCalendarService to apply custom reminders (popup + email) - Add TRPC endpoint for updating reminder settings * fix: address code review feedback - Use z.union with literal values (10, 30, 60) for stricter schema validation - Add localization for toast messages using t() - Fix test data to use null for customCalendarReminder to match test intent * fix: add customCalendarReminder to DestinationCalendar types Update manually-defined DestinationCalendar types to include the new customCalendarReminder field added in the previous commit. This fixes type mismatches when passing Prisma-persisted destination calendars to functions using these local type definitions. * fix: update customCalendarReminder type in test to match Prisma schema The customCalendarReminder field is defined as a non-nullable Int with default value of 10 in the Prisma schema. Changed test value from null to 10 to fix TS2345 type error. * feat: add 'just in time' reminder option for Google Calendar events - Add 0 (just in time) as a valid reminder option alongside 10, 30, 60 minutes - Update TRPC schema to accept 0 as valid reminder value - Add 'Just in time' option to reminder dropdown selector UI - Add translation for 'just_in_time' key in English locale - Include comprehensive test case for 0-minute (just in time) reminders - Remove unused import from test file This addresses reviewer feedback to provide flexible 'just in time' option that allows reminders to fire at exact event start time. 🤖 Generated with Claude Code * fix: add customCalendarReminder to calendars service mock - Add missing customCalendarReminder field to destination calendar mock - Matches the Prisma schema requirement - Fixes type error in calendars controller e2e test * fix: add customCalendarReminder to destination calendars controller test - Add missing customCalendarReminder field to mock destination calendar - Matches Prisma schema requirement - Fixes type error in destination-calendars controller e2e test * fix: cast customCalendarReminder to ReminderMinutes type - Add type cast for reminderValue to ensure type safety - Use nullish coalescing (??) to preserve 0 as valid reminder value - Ensures database number type is properly cast to ReminderMinutes union * refactor: simplify translation logic in DestinationReminderSelector - Remove conditional check for 'just_in_time' label - Pass count parameter to all translations uniformly - Translation function handles unused parameters gracefully Addresses review feedback from @Khaan25 * refactor: make custom calendar reminder opt-in and use repository pattern - Change default from 10 to null (opt-in feature) - Add DestinationCalendarRepository to avoid direct Prisma usage - Add 'Use default reminders' option to UI * refactor: remove redundant migration file The original migration already creates customCalendarReminder as nullable, so this second migration to make it nullable is not needed. * fix: type error for customCalendarReminder in destination calendar settings * refactor: validate customCalendarReminder with Zod schema instead of type casting * refactor: use instance methods in DestinationCalendarRepository Changed from static to instance methods with getInstance() pattern as requested in review. * refactor: replace singleton with DI for DestinationCalendarRepository - Remove getInstance() singleton pattern - Add DI tokens, module, and container - Update GoogleCalendarService and tRPC handler to use DI --------- Co-authored-by: Volnei Munhoz <volnei@cal.com> Co-authored-by: Keith Williams <keithwillcode@gmail.com> Co-authored-by: Eunjae Lee <hey@eunjae.dev>
Customizable UI components to integrate scheduling into your services.
Users guide
Support
Currently supports React 18, React 19, Next 14 and Next 15.
Changelog
- Changelog can be viewed here.
- For upcoming changes in the next release click here to see a pull request titled
chore: version packagescontaining next release changes.
Versioning
- We use semantic versioning meaning that all updates except major should be safe to update.
- If there are breaking changes within a specific version it will be marked as
❗️Breaking changein the changelog, so please check it out before updating. - Some of the versions are suffixed e.g.
1.0.102-framerand are intended for isolated use cases, so you most probably want to use version without any suffix e.g.1.0.103.
Documentation
Documentation on how to get started with platform solution is here and list of atoms can be viewed here
Contributors guide
Versioning
We use a tool called changesets that helps documenting changes related to your development branch and then manages
atoms versioning and publishing to npm. We need to add a log documenting changes and then letting changesets to gather the changes, update Changelog and update version in package.json.
- Let's say you are on a development branch and just finished adding a new feature to atoms. While on the development branch, you have to add a log documenting this feature so that it later ends up in the atoms CHANGELOG.md.
- Run
yarn changesets-addfrom monorepo root and then select@calcom/atomsusing space bar and press enter to go to the next step. - Then, you have to select whether this is a major, minor or patch update following semantic versioning. Since it is a feature skip major by pressing enter and then select minor by pressing space bar and press enter to go to the next step.
- Then, you have to write a description of the change and press enter. This will generate a log file in the
.changesetdirectory e.g..changeset/hungry-donuts-cross.md. - Commit this log file to your development branch and push it.
Notably, you do not have to change
"version"in the atomspackage.jsonfile because changesets will do it in the next step.
- After the development branch is merged changesets will open a pull request titled
chore: version packagescontaining next release changes. This pull request will contain the new log file, it being added to the atomsCHANGELOG.mdfile and changesets will update the atomspackage.jsonfile based whether or not is is major, minor or patch update. When we want to release atoms we simply have to merge this pull request and changesets will publish the new atoms version to npm. Notably, changesets will publish atoms to npm only if the"version"in the atomspackage.jsonof changeset's PR is higher than in the npm.
The following 2 articles teach how to write good change summaries for each PR when it deserves to end up in CHANGELOG.md
Testing
Atoms are tested in CI using e2e tests within the example platform app. To run them locally:
- Go to "packages/platform/atoms" and run
yarn dev-onand thenyarn build- this will create local build of atoms. - Setup environment variables in "packages/platform/examples/base/.env" file. You will need your own platform oAuth client to populate NEXT_PUBLIC_X_CAL_ID (oAuth id), X_CAL_SECRET_KEY (oAuth secret), VITE_BOOKER_EMBED_OAUTH_CLIENT_ID (oAuth id) and ORGANIZATION_ID (organization id to which oAuth client belongs) - all of these are available in the platform settings dashboard after creating the oAuth client.
NEXT_PUBLIC_X_CAL_ID=""
X_CAL_SECRET_KEY=""
NEXT_PUBLIC_CALCOM_API_URL="https://api.cal.com/v2"
VITE_BOOKER_EMBED_OAUTH_CLIENT_ID=""
VITE_BOOKER_EMBED_API_URL="https://api.cal.com/v2"
ORGANIZATION_ID=""
- Go to "packages/platform/examples/base" and run
yarn dev:e2e- this will start the example platform app and run e2e tests by using locally built atoms. Because it is not running within CI it will open a browser and run tests.