feat(calendar): add sendUpdates parameter to createEvent

[allenhutchison]

Summary

Fixes #190 — calendar_createEvent now supports a sendUpdates parameter to control whether attendees receive calendar invitations.

Changes

• CalendarService.ts: Added sendUpdates field to CreateEventInput interface and createEvent method. Defaults to all when attendees are present, none otherwise.
• index.ts: Registered sendUpdates as an optional enum parameter (all, externalOnly, none) on the tool schema.
• CalendarService.test.ts: Added tests for explicit sendUpdates, attendee-present default (all), and no-attendee default (none).

[gemini-code-assist]

Summary of Changes

Hello @allenhutchison, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request primarily focuses on maintaining the project's dependencies by updating several packages to their latest versions, ensuring compatibility and leveraging new features. It also introduces a new functional enhancement to the calendar event creation process, providing more granular control over attendee notifications.

Highlights

• Dependency Updates: Multiple development and production dependencies have been updated, including marked, @types/node, @typescript-eslint/* packages, eslint-plugin-license-header, vite, and vue. This includes a significant update to vite from 6.4.1 to 7.3.1.
• ESLint Peer Dependency Resolution: The eslint-plugin-license-header package was updated to version 0.9.0, which now explicitly supports eslint versions ^9 || ^10, addressing potential peer dependency conflicts.
• Calendar Service Enhancement: The createEvent function in the Calendar Service now supports a sendUpdates parameter, allowing control over sending notifications to event attendees. If attendees are provided and sendUpdates is not specified, it defaults to 'all'.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• package-lock.json
  • Updated marked from 17.0.1 to 17.0.2.
  • Updated @types/node from 25.2.0 to 25.2.3.
  • Updated @typescript-eslint/eslint-plugin from 8.54.0 to 8.55.0.
  • Updated @typescript-eslint/parser from 8.53.0 to 8.55.0.
  • Updated eslint-plugin-license-header from 0.8.0 to 0.9.0.
  • Updated vite from 6.4.1 to 7.3.1.
  • Updated vue from 3.5.27 to 3.5.28.
  • Removed numerous @esbuild optional dependencies previously nested under vite/node_modules.
• package.json
  • Updated marked dependency to ^17.0.2.
  • Updated @types/node dev dependency to ^25.2.3.
  • Updated @typescript-eslint/eslint-plugin dev dependency to ^8.55.0.
  • Updated @typescript-eslint/parser dev dependency to ^8.55.0.
  • Updated eslint-plugin-license-header dev dependency to ^0.9.0.
  • Updated vite dev dependency to ^7.3.1.
  • Updated vue dev dependency to ^3.5.28.
• workspace-server/src/tests/services/CalendarService.test.ts
  • Added sendUpdates: undefined to existing createEvent calls to explicitly test the default behavior.
  • Added a new test case to verify createEvent with an explicit sendUpdates parameter set to 'all'.
  • Added a new test case to confirm sendUpdates defaults to 'all' when attendees are present but sendUpdates is not provided.
• workspace-server/src/index.ts
  • Added sendUpdates as an optional enum parameter ('all', 'externalOnly', 'none') to the createEvent API definition, with a description of its default behavior.
• workspace-server/src/services/CalendarService.ts
  • Added sendUpdates as an optional property to the CreateEventInput interface.
  • Destructured sendUpdates from the input in the createEvent method.
  • Implemented logic to determine finalSendUpdates: if sendUpdates is not provided and attendees exist, it defaults to 'all'.
  • Added logging for the sendUpdates value.
  • Passed the finalSendUpdates value to the calendar.events.insert call.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new sendUpdates parameter to the createEvent function in the Calendar service, allowing for more control over notifications. The changes include updating the tool definition, the service implementation, and adding corresponding tests. The dependency updates seem fine.

I've found one issue where the implementation for the default value of sendUpdates does not fully match the documented behavior. I've left a comment with a suggestion to fix it and to add a missing test case.