* chore: Disables syncing of calendarList on overlay calendar fetch * Unwrap ToggledConnectedCalendars * Pick the right type for connectedCalendars * further type amends * Type fixes, tons of em * Some further fixups consistent with what was before * fix: resolve type incompatibility in getConnectedDestinationCalendars return type Co-Authored-By: alex@cal.com <me@alexvanandel.com> * fix: update DestinationCalendarProps to accept tRPC handler return type Co-Authored-By: alex@cal.com <me@alexvanandel.com> * fix: use generic type for DestinationCalendarProps to accept tRPC enriched types Co-Authored-By: alex@cal.com <me@alexvanandel.com> * fix: simplify DestinationCalendarProps type for better compatibility Co-Authored-By: alex@cal.com <me@alexvanandel.com> * fix: export ConnectedCalendar type for consistent type inference Co-Authored-By: alex@cal.com <me@alexvanandel.com> * fix: use permissive type for connectedCalendars to accept tRPC enriched types Co-Authored-By: alex@cal.com <me@alexvanandel.com> * fix: export ConnectedCalendar and ConnectedDestinationCalendars types from platform-libraries Co-Authored-By: alex@cal.com <me@alexvanandel.com> * fix: update ConnectedCalendar type to use boolean | null for primary field Co-Authored-By: alex@cal.com <me@alexvanandel.com> * Update ConnectedCalendarItem * Undo some of Devins fixes, more fixes * Fixup the destination calendar return type, historically not null * Change init to undefined to deal with null * Approach to connect selected calendars with the right credential * This return type is used way too much everywhere, not refactoring * Add the selectedCalendars to the type * Actually fix overlay calendar * set calendarsToLoad param as required * Apply suggestion from @cubic-dev-ai[bot] Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> * Add new translation for 'Calendar Settings' --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
How to work with platform libraries in Dev
We version this package using NPM: https://www.npmjs.com/package/@calcom/platform-libraries?activeTab=code
Here is the workflow:
- If you change platform libraries for the first time, then run
yarn localto build them locally for the first time. This will also make v2 api point to the local libraries. - If you change them for the second time, then run
yarn build:devto re-build them. - Once you are happy with platform libraries:
- run
yarn publish-npm- it will check "@calcom/platform-libraries" version in npm and update it's package.json to the next version and then it will publish the package to npm, update the version of "@calcom/platform-libraries" in the api v2 package.json, reset "@calcom/platform-libraries" to 0.0.0 and run yarn install.
Before Merging to main
- Publish Your Version of Libraries on NPM:
- To publish, ensure you are a contributor to the platform libraries' NPM package.
- Authenticate yourself via the CLI using npm auth.
- Increment the version number accordingly.
- Run yarn publish to publish your version.
- Once it's published, change back the version in packages/platform/libraries/package.json back to 0.0.0
- Run yarn
- You should now be using the npm package instead of the locally built version
When to publish new version of platform libraries
- New exports in the index.js of platform libraries
- Code change in the functions already exported
- Prisma schema change breaking implementation of functions in the currently used releases of platform libraries