feat: refactor schema to use regex for date and month

[ryoppippi]

This pull request improves the validation of date and month fields in the src/data-loader.ts file by introducing stricter regex-based validation for formatting. The changes ensure that these fields conform to expected formats (YYYY-MM-DD for dates and YYYY-MM for months).

Validation improvements:

• src/data-loader.ts: Updated DailyUsageSchema to validate the date field using a regex pattern that enforces the YYYY-MM-DD format.
• src/data-loader.ts: Updated MonthlyUsageSchema to validate the month field using a regex pattern that enforces the YYYY-MM format.

[gemini-code-assist]

Hello @ryoppippi, 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!

Summary of Changes

As gemini-code-assist, I've reviewed this pull request authored by ryoppippi. The core purpose of this change is to enhance the data validation within the src/data-loader.ts file. It achieves this by implementing stricter format checks for the date field in the DailyUsageSchema and the month field in the MonthlyUsageSchema. Regular expressions are now used to ensure that dates conform to the YYYY-MM-DD format and months conform to the YYYY-MM format, improving data integrity.

Highlights

• Improved Data Validation: Introduces regex-based validation for the date and month fields in the usage schemas to enforce specific YYYY-MM-DD and YYYY-MM formats.
• Schema Updates: Modifies the DailyUsageSchema and MonthlyUsageSchema in src/data-loader.ts to use v.pipe with v.regex for the respective date and month fields.

Changelog

• src/data-loader.ts
  • Updated DailyUsageSchema (lines 35-38) to add a regex validation (/^d{4}-d{2}-d{2}$/) to the date field, ensuring it matches the YYYY-MM-DD format.
  • Updated MonthlyUsageSchema (lines 63-66) to add a regex validation (/^d{4}-d{2}$/) to the month field, ensuring it matches the YYYY-MM format.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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 is currently in preview and 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 to provide feedback.

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. ↩

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/ryoppippi/ccusage@22

commit: 938d6e9

[Copilot]

Pull Request Overview

This PR tightens validation rules by enforcing specific date (YYYY-MM-DD) and month (YYYY-MM) formats via regex in the data loader schemas.

• Added v.regex checks in DailyUsageSchema for dates.
• Added v.regex checks in MonthlyUsageSchema for months.

Comments suppressed due to low confidence (2)

src/data-loader.ts:37

• [nitpick] Consider providing a custom error message for the regex validation to make failures clearer to consumers rather than relying on a generic default.

v.regex(/^\d{4}-\d{2}-\d{2}$/), // YYYY-MM-DD format

src/data-loader.ts:35

• Add unit tests covering these new regex validations to ensure both valid and invalid date/month formats are correctly accepted or rejected.

date: v.pipe(

[gemini-code-assist]

Code Review

This pull request makes a good step towards stricter validation for date and month fields by introducing regex. The changes improve format enforcement in DailyUsageSchema and MonthlyUsageSchema.

I have a couple of suggestions to further enhance the robustness of these validations, particularly concerning the actual calendar validity of dates and months, not just their string format. This will help prevent potential issues with data processing, such as sorting or filtering, if malformed (though correctly formatted) date/month strings were to enter the system.

Summary of Findings

• Date field validation robustness: The DailyUsageSchema.date field validation checks for YYYY-MM-DD format but allows invalid calendar dates (e.g., 2023-02-31). This could lead to issues in sorting or date calculations. Suggested using v.isoDate() for stricter validation.
• Month field validation precision: The MonthlyUsageSchema.month field validation checks for YYYY-MM format but allows invalid month numbers (e.g., 2023-13). Suggested a more precise regex ^\d{4}-(0[1-9]|1[0-2])$.

Merge Readiness

The pull request introduces useful regex-based format validation. However, there are opportunities to make these validations more robust by ensuring calendar validity for dates and month numbers, not just string patterns. I've identified one high severity and one medium severity issue related to this.

I recommend addressing these suggestions to improve data integrity and prevent potential downstream issues. As I am an AI, I am not authorized to approve pull requests; please ensure further review and approval from team members before merging.

[gemini-code-assist]

The current regex ^\d{4}-\d{2}-\d{2}$ validates the YYYY-MM-DD format, which is a good improvement. However, it doesn't guarantee that the date is a valid calendar date (e.g., 2023-02-31 would pass this regex).

If this date field is used in date-based calculations or sorting (as it is on line 207: new Date(item.date).getTime()), an invalid calendar date could lead to unexpected behavior or errors (e.g., new Date('2023-02-31') might be interpreted as March 3rd, 2023, affecting sort order).

Consider using valibot's v.isoDate() transformation for more robust validation. It ensures the string is not only in YYYY-MM-DD format but also represents a valid calendar date. This would make the schema more resilient.

What are your thoughts on using v.isoDate() here for stronger validation?

Suggested change

	date: v.pipe(
	v.string(),
	v.regex(/^\d{4}-\d{2}-\d{2}$/), // YYYY-MM-DD format
	),
	date: v.pipe(
	v.string(),
	v.isoDate("Date must be a valid ISO 8601 date in YYYY-MM-DD format") // Ensures YYYY-MM-DD format and calendar validity
	),

[gemini-code-assist]

Similar to the date field, the regex ^\d{4}-\d{2}$ for the month field validates the YYYY-MM format but doesn't ensure the month part is valid (e.g., 2023-00 or 2023-13 would pass).

While the current data generation logic (line 334: data.date.substring(0, 7)) likely produces valid months, making the schema validation itself stricter would improve its robustness, especially if this schema were used to parse data from other sources.

Would you consider using a more precise regex to ensure the month is between 01 and 12? For example: ^\d{4}-(0[1-9]|1[0-2])$.

Suggested change

	month: v.pipe(
	v.string(),
	v.regex(/^\d{4}-\d{2}$/), // YYYY-MM format
	),
	month: v.pipe(
	v.string(),
	v.regex(/^\d{4}-(0[1-9]|1[0-2])$/, "Month must be in YYYY-MM format with a valid month (01-12)") // YYYY-MM format, validates month 01-12
	),