feat: Remove support for expired Dart and Flutter versions #1052
Conversation
|
🚀 Thanks for opening this pull request! |
|
Warning Rate limit exceeded@mtrezza has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 14 minutes and 54 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughAdds CI/dependency automation and versioning docs, raises Dart/Flutter SDK constraints, introduces a version-support checker and issue template, and applies widespread formatting changes across library and test files; no functional library API changes besides a few public typedef/typedef additions in Flutter live-list. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #1052 +/- ##
==========================================
- Coverage 43.55% 43.46% -0.10%
==========================================
Files 61 61
Lines 3577 3587 +10
==========================================
+ Hits 1558 1559 +1
- Misses 2019 2028 +9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/dart/README.md (1)
40-45: Critical: End of Support dates don't match the 6-month policy.The EOL dates in the compatibility table don't align with the stated 6-month support window. Based on the release dates in
scripts/check-version-support.js:
- Dart 3.2 (released 2023-11-15): Next version 3.3 released 2024-02-15 → EOL should be Aug 2024, not Jan 2025
- Dart 3.3 (released 2024-02-15): Next version 3.4 released 2024-05-15 → EOL should be Nov 2024, not Apr 2025
- Dart 3.4 (released 2024-05-15): Next version 3.5 released 2024-08-15 → EOL should be Feb 2025, not Jun 2025
- Dart 3.5 (released 2024-08-15): No next version yet → EOL is N/A or TBD
Run the check-version-support.js script to generate the correct table:
#!/bin/bash # Generate correct EOL dates using the version support script node scripts/check-version-support.jsThe script output includes markdown tables that can be copied directly into the README.
🧹 Nitpick comments (12)
.github/dependabot.yml (1)
11-12: Consider using "chore" prefix for dependency updates.Using "feat" as the commit prefix for dependency updates may trigger feature releases when the updates don't add new features. Consider using "chore" or "build" instead, unless your semantic-release configuration specifically requires "feat" for patch releases.
Apply this diff if you want to use "chore" prefix:
commit-message: - prefix: "feat" + prefix: "chore"Also applies to: 22-23
.github/workflows/dependency-audit.yml (1)
30-36: Avoid duplicate command execution in audit steps.The outdated dependency checks run the same command twice (once to console, once to summary), which is inefficient.
Use
teeto output to both destinations in a single command:- name: Check for outdated dependencies id: outdated working-directory: packages/dart run: | echo "## Dart Package - Outdated Dependencies" >> $GITHUB_STEP_SUMMARY - dart pub outdated --mode=outdated || true - dart pub outdated --mode=outdated >> $GITHUB_STEP_SUMMARY || true + dart pub outdated --mode=outdated | tee -a $GITHUB_STEP_SUMMARY || trueAlso applies to: 62-68
scripts/check-version-support.js (1)
18-31: Add validation comments for manual release date updates.The hardcoded release dates require manual updates. Consider adding a comment with the source URL for these dates to help maintainers keep them current.
// Dart version releases (update this manually as new versions are released) +// Source: https://dart.dev/get-dart/archive const DART_RELEASES = [ { version: '3.2', latest: '3.2.6', releaseDate: '2023-11-15' }, { version: '3.3', latest: '3.3.4', releaseDate: '2024-02-15' }, { version: '3.4', latest: '3.4.4', releaseDate: '2024-05-15' }, { version: '3.5', latest: '3.5.3', releaseDate: '2024-08-15' }, ]; // Flutter version releases (update this manually as new versions are released) +// Source: https://docs.flutter.dev/release/archive const FLUTTER_RELEASES = [ { version: '3.16', latest: '3.16.9', releaseDate: '2023-11-15' }, { version: '3.19', latest: '3.19.6', releaseDate: '2024-02-15' }, { version: '3.22', latest: '3.22.3', releaseDate: '2024-05-15' }, { version: '3.24', latest: '3.24.3', releaseDate: '2024-08-15' }, ];.github/ISSUE_TEMPLATE/---3-version-conflict.md (1)
40-43: Add language identifier to error message code block.The code block for the error message should specify a language for proper syntax highlighting and to satisfy markdown linting rules.
**Error Message:** -``` +```text Paste the full error message from `dart pub get` or `flutter pub get`</blockquote></details> <details> <summary>VERSIONING_POLICY.md (1)</summary><blockquote> `36-43`: **Clarify "API impact" criteria in version bump table.** The distinction between "breaking API impact," "non-breaking API impact," and "without API impact" for major dependency changes may be unclear to contributors. Consider adding examples or a footnote explaining what constitutes each category. Add a footnote or examples section: ```diff | Major with breaking API impact | Major | | Major with non-breaking API impact | Minor | | Major without API impact | Patch | | Minor | Patch | | Patch | Patch | + +**Examples:** +- Breaking API impact: Dependency changes a method signature we expose in our public API +- Non-breaking API impact: Dependency adds new features we expose +- Without API impact: Dependency is internal-only or changes don't affect our public APIMIGRATION_GUIDES.md (7)
21-25: Add language specifier to code block.Code blocks should specify their language for syntax highlighting. This error output block should use a language identifier.
-``` +```plaintext Because your_app depends on parse_server_sdk ^8.0.0 which depends on dio ^5.0.0, and your_app depends on another_package ^2.0.0 which depends on dio ^6.0.0, version solving failed. -``` +```
51-51: Wrap bare URL in markdown link syntax.Bare URLs should be wrapped in markdown links for better formatting and accessibility.
-1. Go to https://github.com/parse-community/Parse-SDK-Flutter/issues +1. Go to [Parse SDK issues](https://github.com/parse-community/Parse-SDK-Flutter/issues)
79-82: Add language specifier to code block.This error output code block should specify a language identifier for consistency with other blocks in the document.
-``` +```plaintext Because parse_server_sdk >=8.0.0 requires SDK version >=3.2.6 <4.0.0, and your project has SDK version 2.19.0, version solving failed. -``` +```
113-114: Wrap bare URLs in markdown links.For consistency and better formatting, these URLs should be wrapped in markdown link syntax rather than appearing as bare URLs.
-Dart migration: https://dart.dev/guides/language/evolution -Flutter migration: https://docs.flutter.dev/release/breaking-changes +Dart migration: [https://dart.dev/guides/language/evolution](https://dart.dev/guides/language/evolution) +Flutter migration: [https://docs.flutter.dev/release/breaking-changes](https://docs.flutter.dev/release/breaking-changes)
154-157: Add language specifier to code block.This error output block should include a language identifier for consistency.
-``` +```plaintext Because package_a depends on http ^0.13.0 and package_b depends on http ^1.0.0, and both are required by your app, version solving failed. -``` +```
188-188: Fix heading level to skip only one level.Markdown heading levels should increment by only one level at a time. Change this h4 to h3.
-#### I Need Dart 3+ Features But Parse SDK Doesn't Support Them Yet <!-- omit in toc --> +### I Need Dart 3+ Features But Parse SDK Doesn't Support Them Yet <!-- omit in toc -->
194-194: Hyphenate compound modifier."Dart 2.x compatible" should be hyphenated as "Dart 2.x-compatible" when used as a compound modifier before "patterns".
-4. Temporarily use Dart 2.x compatible patterns +4. Temporarily use Dart 2.x-compatible patterns
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
.github/ISSUE_TEMPLATE/---3-version-conflict.md(1 hunks).github/dependabot.yml(1 hunks).github/workflows/ci.yml(6 hunks).github/workflows/dependency-audit.yml(1 hunks)CONTRIBUTING.md(1 hunks)MIGRATION_GUIDES.md(1 hunks)VERSIONING_POLICY.md(1 hunks)packages/dart/README.md(3 hunks)packages/flutter/README.md(3 hunks)scripts/check-version-support.js(1 hunks)
🧰 Additional context used
🪛 LanguageTool
MIGRATION_GUIDES.md
[grammar] ~194-~194: Use a hyphen to join words.
Context: ...ate yourself 4. Temporarily use Dart 2.x compatible patterns ### CI/CD Pipeline ...
(QB_NEW_EN_HYPHEN)
VERSIONING_POLICY.md
[style] ~10-~10: Some style guides suggest that commas should set off the year in a month-day-year date.
Context: ...:** - Dart 3.3.0 released: February 15, 2024 - Dart 3.2.x end-of-support: August 15,...
(MISSING_COMMA_AFTER_YEAR)
packages/dart/README.md
[style] ~35-~35: Using many exclamation marks might seem excessive (in this case: 4 exclamation marks for a text that’s 2788 characters long)
Context: ...ificant version (major or minor).
[!Note]
Support windows are calculated ...
(EN_EXCESSIVE_EXCLAMATION)
[style] ~36-~36: ‘advance notice’ might be wordy. Consider a shorter alternative.
Context: ...he next Parse SDK major release without advance notice. For full details, see [VERSIONING_POLI...
(EN_WORDINESS_PREMIUM_ADVANCE_NOTICE)
packages/flutter/README.md
[style] ~38-~38: Using many exclamation marks might seem excessive (in this case: 5 exclamation marks for a text that’s 3110 characters long)
Context: ...heck both SDK compatibility tables. > [!Note] > Support windows are calculated f...
(EN_EXCESSIVE_EXCLAMATION)
[style] ~39-~39: ‘advance notice’ might be wordy. Consider a shorter alternative.
Context: ...he next Parse SDK major release without advance notice. For full details, see [VERSIONING_POLI...
(EN_WORDINESS_PREMIUM_ADVANCE_NOTICE)
🪛 markdownlint-cli2 (0.18.1)
.github/ISSUE_TEMPLATE/---3-version-conflict.md
41-41: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
MIGRATION_GUIDES.md
21-21: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
51-51: Bare URL used
(MD034, no-bare-urls)
74-74: Link fragments should be valid
(MD051, link-fragments)
79-79: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
113-113: Bare URL used
(MD034, no-bare-urls)
114-114: Bare URL used
(MD034, no-bare-urls)
154-154: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
188-188: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
packages/flutter/README.md
37-37: Blank line inside blockquote
(MD028, no-blanks-blockquote)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Test Dart 3.2
- GitHub Check: Test Dart 3.3
- GitHub Check: Test Dart 3.5, macOS
- GitHub Check: Test Dart 3.5, Windows
- GitHub Check: Test Flutter 3.24, Windows
- GitHub Check: Test Flutter beta
- GitHub Check: Test Flutter 3.24, macOS
🔇 Additional comments (14)
.github/workflows/ci.yml (1)
17-19: LGTM! Clear documentation of version support policy.The added comments effectively document the 6-month support window policy and reference the comprehensive VERSIONING_POLICY.md. This helps maintainers understand when to remove older versions from the CI matrix.
Also applies to: 32-32, 42-42, 87-89, 102-102, 112-112
scripts/check-version-support.js (3)
38-42: LGTM! EOL calculation logic is correct.The function correctly adds 6 months to the next release date to calculate the end-of-support date, which aligns with the stated policy.
252-254: Module exports are well-structured.The script properly exports key functions for programmatic use while supporting CLI execution, following Node.js best practices.
49-51: Based on my verification through official sources, I've found important discrepancies in the review comment's verification request. Let me provide the rewritten review comment:
Verify timezone-aware date handling and correct release date references.
The
formatDatefunction usestoISOString()which converts to UTC. If the input dates are intended to be in a specific timezone, this could cause off-by-one-day errors. However, the release dates cited in the verification request contain inaccuracies:
- Dart 3.2: November 15, 2023 ✓
- Dart 3.3: February 15, 2024 ✓
- Dart 3.4: May 14, 2024 (not May 15)
- Dart 3.5: August 6, 2024 (not August 15)
Verify that the actual release dates in the
DART_RELEASESandFLUTTER_RELEASESarrays match official sources:If the script contains incorrect dates, they should be corrected. Additionally, consider whether the UTC conversion in
formatDatealigns with the intended timezone semantics.CONTRIBUTING.md (1)
13-26: LGTM! Clear contribution guidance added.The new sections effectively guide contributors on commit message format, dependency management, and framework support policy. The cross-reference to VERSIONING_POLICY.md ensures contributors can find detailed information when needed.
.github/ISSUE_TEMPLATE/---3-version-conflict.md (1)
1-77: LGTM! Comprehensive issue template.The template provides a well-structured format for users to report version conflicts, with all necessary information fields and helpful references to migration guides. This will make it easier to triage and resolve dependency issues.
VERSIONING_POLICY.md (1)
1-68: LGTM! Comprehensive and clear versioning policy.The document effectively addresses the issue #968 by establishing a 6-month support window based on the next significant version release date, rather than the previous "1 year after release" policy. The policy is well-structured, includes practical examples, and provides clear guidance for maintainers.
packages/dart/README.md (2)
33-36: LGTM! Policy clearly states the new 6-month support window.The updated compatibility section correctly reflects the PR objective: changing from "1 year after release" to "6 months after the next significant version release." The note about support windows and the reference to VERSIONING_POLICY.md provide helpful context.
47-57: Helpful troubleshooting guidance for version conflicts.The numbered checklist and reference to the Version Conflict Guide provide a clear path for users encountering dependency issues. This aligns well with the new issue template and policy documentation.
packages/flutter/README.md (3)
33-33: Verify policy window aligns with VERSIONING_POLICY.md.The README states a 6-month support window, but the PR objectives reference a 12-month upgrade window based on the next significant Dart/Flutter release. Confirm that the 6-month window is intentional for Flutter specifically (with 12 months potentially applying to Dart), or if this should be harmonized. This should be consistent with the referenced VERSIONING_POLICY.md.
43-48: Verify end-of-support dates are correctly calculated.Ensure that each end-of-support date is accurately calculated as 6 months from the release date of the next higher Flutter version (not from the version's own release date). Provide verification that these dates align with official Flutter release dates.
50-60: Clear, actionable conflict resolution guidance.The Handling Version Conflicts section provides a practical step-by-step approach with proper cross-references to MIGRATION_GUIDES.md and related documentation. Well structured for developer self-service.
MIGRATION_GUIDES.md (2)
196-220: Well-structured CI/CD troubleshooting guidance.Clear step-by-step instructions with appropriate code examples and proper language specifiers. Covers version verification, cache management, and dependency repair.
221-247: Comprehensive coverage of platform-specific and device support scenarios.Good practical guidance on Flutter Web conflicts and device support considerations, with clear resource links and policy references. The additional resources section properly directs readers to versioning policy and related documentation.
mtrezza
changed the title
|
BREAKING CHANGE: This release removes support for Dart 3.2 - 3.9 and Flutter 3.16 - 3.37. These versions exceeded their 6-month support window after the next significant version release. The minimum required versions are now Dart 3.10 and Flutter 3.38. |
mtrezza
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
packages/dart/test/src/objects/parse_object/parse_object_fetch_test.dart (1)
72-72: Minor typo in mock URL.The URL contains "exampe.com" instead of "example.com". While this is test mock data that's never actually called, fixing it would improve consistency.
- "url": "https://exampe.com/gyBUISapgwfxB/resume.txt", + "url": "https://example.com/gyBUISapgwfxB/resume.txt",packages/dart/test/src/objects/parse_object/parse_object_delete_eventually_test.dart (1)
34-52: deleteEventually mocks align with intended control flowStubbing
client1.deletewithanycleanly forces the initial failure, and theclient2.deletestub with asuccesspayload still matches the expected shape for clearing the eventual delete queue; the assertions over the CoreStore lists remain valid.packages/dart/test/src/objects/parse_object/parse_object_delete_test.dart (3)
90-93: Good use of full JSON snapshots around error pathCapturing
dietPlansObject.toJson(full: true)before and after a failing delete and asserting equality is a solid way to guarantee the object’s state is not mutated on error. The mock and verification for the single delete call look consistent with that intent.Also applies to: 100-101, 120-123, 129-132
135-193: New delete(id: id) coverage is strong; consider one extra edge checkThis new test mirrors the objectId-based success test and nicely validates URL construction, response handling, and data/state equality when using the explicit
idparameter.
To make it even more robust, you could also cover the case wheredietPlansObject.objectIdis set to a different value thanid, and assert that the delete still targetsidand that no network call is made to the mismatched objectId URL.
195-217: Invalid-argument delete() test behavior is clearThe test correctly asserts that
delete()throws when bothobjectIdandidare null or empty, and that the client mock sees no interactions, which tightly guards the early-validation branch.
As a non-functional nit, you could adjust the description to “…both objectId and id parameters are null or empty” for slightly clearer wording.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (55)
.gitignore(1 hunks)packages/dart/lib/parse_server_sdk.dart(1 hunks)packages/dart/lib/src/data/parse_core_data.dart(2 hunks)packages/dart/lib/src/data/parse_subclass_handler.dart(1 hunks)packages/dart/lib/src/network/parse_client.dart(1 hunks)packages/dart/lib/src/network/parse_dio_client.dart(2 hunks)packages/dart/lib/src/network/parse_http_client.dart(1 hunks)packages/dart/lib/src/network/parse_live_query.dart(2 hunks)packages/dart/lib/src/network/parse_query.dart(1 hunks)packages/dart/lib/src/objects/parse_acl.dart(1 hunks)packages/dart/lib/src/objects/parse_base.dart(1 hunks)packages/dart/lib/src/objects/parse_config.dart(1 hunks)packages/dart/lib/src/objects/parse_file_base.dart(2 hunks)packages/dart/lib/src/objects/parse_function.dart(1 hunks)packages/dart/lib/src/objects/parse_geo_point.dart(1 hunks)packages/dart/lib/src/objects/parse_installation.dart(3 hunks)packages/dart/lib/src/objects/parse_object.dart(2 hunks)packages/dart/lib/src/objects/parse_operation/parse_operation.dart(1 hunks)packages/dart/lib/src/objects/parse_operation/parse_remove_relation_operation.dart(1 hunks)packages/dart/lib/src/objects/parse_relation.dart(1 hunks)packages/dart/lib/src/objects/parse_session.dart(1 hunks)packages/dart/lib/src/objects/parse_user.dart(5 hunks)packages/dart/lib/src/objects/parse_x_file.dart(1 hunks)packages/dart/lib/src/storage/core_store_sem_impl.dart(1 hunks)packages/dart/lib/src/utils/parse_decoder.dart(1 hunks)packages/dart/lib/src/utils/parse_encoder.dart(1 hunks)packages/dart/lib/src/utils/parse_live_list.dart(20 hunks)packages/dart/lib/src/utils/parse_logger.dart(3 hunks)packages/dart/lib/src/utils/parse_login_helpers.dart(1 hunks)packages/dart/lib/src/utils/parse_utils.dart(4 hunks)packages/dart/test/parse_query_test.mocks.dart(1 hunks)packages/dart/test/src/network/parse_live_query_test.dart(1 hunks)packages/dart/test/src/network/parse_query_test.dart(13 hunks)packages/dart/test/src/network/parse_query_test.mocks.dart(7 hunks)packages/dart/test/src/objects/parse_base_test.dart(3 hunks)packages/dart/test/src/objects/parse_object/parse_object_array_test.dart(11 hunks)packages/dart/test/src/objects/parse_object/parse_object_create_test.dart(2 hunks)packages/dart/test/src/objects/parse_object/parse_object_delete_eventually_test.dart(1 hunks)packages/dart/test/src/objects/parse_object/parse_object_delete_test.dart(5 hunks)packages/dart/test/src/objects/parse_object/parse_object_distinct_test.dart(7 hunks)packages/dart/test/src/objects/parse_object/parse_object_fetch_test.dart(3 hunks)packages/dart/test/src/objects/parse_object/parse_object_get_all_test.dart(6 hunks)packages/dart/test/src/objects/parse_object/parse_object_get_object_test.dart(2 hunks)packages/dart/test/src/objects/parse_object/parse_object_increment_decrement_test.dart(12 hunks)packages/dart/test/src/objects/parse_object/parse_object_query_test.dart(6 hunks)packages/dart/test/src/objects/parse_object/parse_object_relation_test.dart(12 hunks)packages/dart/test/src/objects/parse_object/parse_object_save_eventually_test.dart(1 hunks)packages/dart/test/src/objects/parse_object/parse_object_save_test.dart(10 hunks)packages/dart/test/src/objects/parse_object/parse_object_test.dart(1 hunks)packages/dart/test/src/objects/parse_object/parse_object_test.mocks.dart(7 hunks)packages/dart/test/src/objects/parse_object/parse_object_unset_test.dart(2 hunks)packages/dart/test/src/objects/parse_object/parse_object_update_test.dart(3 hunks)packages/dart/test/src/objects/response/parse_response_utils_test.dart(1 hunks)packages/dart/test/src/utils/parse_encoder_test.dart(2 hunks)packages/dart/test/test_utils.dart(3 hunks)
✅ Files skipped from review due to trivial changes (36)
- packages/dart/test/src/objects/parse_object/parse_object_save_eventually_test.dart
- packages/dart/lib/src/objects/parse_relation.dart
- packages/dart/test/src/objects/parse_object/parse_object_unset_test.dart
- .gitignore
- packages/dart/lib/src/objects/parse_operation/parse_operation.dart
- packages/dart/lib/src/utils/parse_login_helpers.dart
- packages/dart/lib/src/objects/parse_config.dart
- packages/dart/lib/src/objects/parse_operation/parse_remove_relation_operation.dart
- packages/dart/lib/src/objects/parse_x_file.dart
- packages/dart/test/src/objects/parse_object/parse_object_create_test.dart
- packages/dart/test/src/objects/response/parse_response_utils_test.dart
- packages/dart/lib/src/objects/parse_acl.dart
- packages/dart/lib/src/objects/parse_object.dart
- packages/dart/test/src/network/parse_query_test.mocks.dart
- packages/dart/test/src/objects/parse_object/parse_object_update_test.dart
- packages/dart/lib/src/objects/parse_session.dart
- packages/dart/lib/src/objects/parse_installation.dart
- packages/dart/test/src/objects/parse_object/parse_object_save_test.dart
- packages/dart/lib/src/utils/parse_decoder.dart
- packages/dart/test/test_utils.dart
- packages/dart/lib/src/storage/core_store_sem_impl.dart
- packages/dart/test/src/network/parse_query_test.dart
- packages/dart/lib/src/data/parse_subclass_handler.dart
- packages/dart/test/src/objects/parse_object/parse_object_query_test.dart
- packages/dart/test/src/objects/parse_base_test.dart
- packages/dart/lib/parse_server_sdk.dart
- packages/dart/lib/src/objects/parse_base.dart
- packages/dart/lib/src/objects/parse_file_base.dart
- packages/dart/lib/src/objects/parse_user.dart
- packages/dart/test/src/objects/parse_object/parse_object_get_object_test.dart
- packages/dart/test/src/objects/parse_object/parse_object_array_test.dart
- packages/dart/test/src/utils/parse_encoder_test.dart
- packages/dart/test/src/network/parse_live_query_test.dart
- packages/dart/lib/src/network/parse_dio_client.dart
- packages/dart/lib/src/utils/parse_encoder.dart
- packages/dart/lib/src/utils/parse_live_list.dart
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Test Flutter beta
- GitHub Check: Test Flutter 3.38, Windows
- GitHub Check: Test Dart 3.10, Ubuntu
🔇 Additional comments (29)
packages/dart/lib/src/network/parse_live_query.dart (2)
141-142: Broadcast stream initialization remains correct
_clientEventStreamis still derived via.asBroadcastStream(), so multiple listeners (e.g., reconnect controller and others) remain supported; this looks like a formatting-only change with no behavioral impact.
172-174: Singleton instance construction stays behaviorally identicalThe introduction of the local
instancevariable with_instance ?? LiveQueryClient._internal(...)and the subsequent_instance ??= instancekeeps lazy, memoized singleton semantics unchanged; this is a harmless readability/formatting tweak.packages/dart/lib/src/network/parse_query.dart (1)
769-773: Behavior-preserving cascade formatting infirst()The refactor to
(QueryBuilder.copy(this)..setLimit(1)).query()is purely stylistic; the cascade and method call order are unchanged and behavior remains identical.packages/dart/lib/src/objects/parse_function.dart (1)
13-16: LGTM!The reformatted constructor initializer list improves readability while preserving all functional behavior. The indentation is consistent and follows Dart formatting conventions.
packages/dart/lib/src/network/parse_http_client.dart (1)
141-144: LGTM!The constructor initializer list reformatting improves readability and aligns with Dart's multi-line formatting conventions. No functional changes.
packages/dart/lib/src/data/parse_core_data.dart (2)
55-59: LGTM!The multi-line reformatting of the null-coalescing assignment improves readability without changing behavior.
68-74: LGTM!The multi-line reformatting of the
clientCreatordefault factory assignment enhances clarity. No functional changes.packages/dart/lib/src/utils/parse_logger.dart (3)
3-7: LGTM!Function signature reformatted with one parameter per line for improved readability. No functional changes.
26-28: LGTM!The ternary expression reformatted to multi-line style improves readability. Logic remains unchanged.
38-44: LGTM!Function signature reformatted with one parameter per line, consistent with the
logAPIResponseformatting above.packages/dart/lib/src/network/parse_client.dart (1)
3-7: LGTM!The typedef reformatting improves readability with no functional changes to the signature.
packages/dart/lib/src/utils/parse_utils.dart (5)
42-60: LGTM!The multiline formatting for the function signature and
Uriconstructor improves readability. No semantic changes.
63-81: LGTM!Consistent multiline formatting applied to match
getSanitisedUri. No semantic changes.
93-124: LGTM!Formatting changes to function signature, client initialization, and method calls improve readability. Logic remains unchanged.
136-141: LGTM!Minor formatting adjustments to
groupFoldByandremoveWherecalls. Behavior unchanged.
161-163: LGTM!Multiline formatting for the
getStringListcall is consistent with other changes in this file.packages/dart/test/src/objects/parse_object/parse_object_relation_test.dart (1)
1-628: LGTM! Formatting changes align with Dart SDK upgrade.All changes in this file are purely cosmetic formatting adjustments (trailing commas, line breaks, indentation) with no modifications to test logic, assertions, or behavior. These changes are consistent with running
dart formatusing a newer Dart SDK version, which aligns with the PR's objective of upgrading to newer Dart/Flutter versions.packages/dart/test/parse_query_test.mocks.dart (1)
1-139: LGTM! Auto-generated mock formatting updates.This Mockito-generated file has been updated with expanded formatting (additional line breaks, trailing commas, aligned blocks) consistent with modern Dart style. No functional changes—all method signatures, return types, and mock behaviors remain identical.
packages/dart/test/src/objects/parse_object/parse_object_distinct_test.dart (2)
37-86: LGTM! Formatting improvements follow Dart best practices.The multi-line test description and trailing commas in the JSON payloads are excellent improvements that enhance code formatting and maintainability.
92-97: LGTM! Cleaner Mockito stub and verification calls.The simplified single-line
when()stubs and cleaned-upverify()calls improve readability without changing behavior.Also applies to: 124-124, 133-133, 153-153
packages/dart/test/src/objects/parse_object/parse_object_fetch_test.dart (1)
36-82: Good expansion of test data for better coverage.The expanded owner object structure (lines 51-62) now includes realistic ACL permissions, timestamps, and type information, providing more comprehensive test coverage for nested Parse objects with relations. The test data effectively covers various Parse data types (Pointer, GeoPoint, File, Relation).
packages/dart/test/src/objects/parse_object/parse_object_increment_decrement_test.dart (4)
29-84: LGTM! Test refactoring and math are correct.The test descriptions are now more concise, and the inlined JSON data improves readability. The mathematical expectations are correct (2.5 + 2.5 = 5.0).
85-200: LGTM! Added test coverage is valuable.The new tests for
setIncrement()andsetDecrement()accounting for previously set values strengthen the test suite. All mathematical expectations are correct.
300-365: Async test logic is sound, but note timing dependency.The test correctly verifies that concurrent increments during
save()are tracked separately. However, the test relies on hardcoded delays (100ms mock response, 150ms wait), which could theoretically cause flakiness in slow environments.Consider verifying that CI environments have sufficient resources to reliably meet these timing expectations, especially if you observe intermittent test failures.
367-406: LGTM! Error handling test is well-structured.The test correctly verifies that internal state remains consistent when
save()fails, ensuring no corruption occurs during error scenarios.packages/dart/test/src/objects/parse_object/parse_object_test.dart (1)
9-10: String reflow keeps test description intactThe concatenated description still reads correctly and this is a pure formatting change with no impact on test behavior.
packages/dart/test/src/objects/parse_object/parse_object_test.mocks.dart (1)
27-41: Generated mocks appear unchanged semanticallyThe constructor reflow for
_Fake*classes and theMockParseClientnoSuchMethod stubs maintain the same invocations and return types; changes are formatting-only and safe to keep as regenerated output.Also applies to: 52-58, 66-82, 91-103, 112-124, 135-161, 169-177, 187-211
packages/dart/test/src/objects/parse_object/parse_object_get_all_test.dart (1)
49-55: Formatting and mock setup changes preserve test behaviorTrailing commas in the
desiredOutputmap and the expandedwhen/verifyblocks keep the same data and call patterns; the length check againstdesiredOutput["results"]!.lengthremains valid given the inferredListtype.Also applies to: 69-80, 83-94, 108-116, 126-133, 152-158
packages/dart/test/src/objects/parse_object/parse_object_delete_test.dart (1)
26-27: Core delete() success test remains soundThe reflowed description and more compact
when/verifycalls still assert the same behavior: correct delete URL, a successful 200 response, and unchanged object JSON after deletion viaobjectId. No functional changes here.Also applies to: 41-47, 79-82
| assert( | ||
| latitude < 180, | ||
| 'Longitude must be within the range (-180.0, 180.0).', | ||
| ), | ||
| assert( | ||
| latitude > -180, | ||
| 'Longitude must be within the range (-180.0, 180.0).', | ||
| ); |
There was a problem hiding this comment.
Critical: Longitude validation checks wrong variable.
Lines 14-17 and 18-21 validate latitude against longitude bounds instead of validating longitude. This means:
- Longitude is never validated, allowing invalid coordinates like
(0.0, 200.0)to pass. - Valid latitudes in the range [90, 180) would incorrectly fail the assertion.
Apply this diff to fix the validation:
assert(
- latitude < 180,
+ longitude < 180,
'Longitude must be within the range (-180.0, 180.0).',
),
assert(
- latitude > -180,
+ longitude > -180,
'Longitude must be within the range (-180.0, 180.0).',
);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| assert( | |
| latitude < 180, | |
| 'Longitude must be within the range (-180.0, 180.0).', | |
| ), | |
| assert( | |
| latitude > -180, | |
| 'Longitude must be within the range (-180.0, 180.0).', | |
| ); | |
| assert( | |
| longitude < 180, | |
| 'Longitude must be within the range (-180.0, 180.0).', | |
| ), | |
| assert( | |
| longitude > -180, | |
| 'Longitude must be within the range (-180.0, 180.0).', | |
| ); |
🤖 Prompt for AI Agents
In packages/dart/lib/src/objects/parse_geo_point.dart around lines 14 to 21, the
two assertion checks are incorrectly validating the variable latitude against
longitude bounds; change both assertions to validate longitude instead (i.e.,
assert(longitude < 180, 'Longitude must be within the range (-180.0, 180.0).')
and assert(longitude > -180, 'Longitude must be within the range (-180.0,
180.0).')), leaving the messages intact so longitude is actually validated and
latitude assertions remain correct elsewhere.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.gitattributes (1)
4-15: Consider extending coverage to other generated file types.While
*.mocks.dartis covered, other generated files (e.g.,*.g.dartfrombuild_runner,*.config.dart, etc.) may also benefit from explicit LF normalization. You might preemptively add them here or document which generated patterns are already handled by the auto-normalize fallback.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.gitattributes(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Test Dart 3.10, macOS
- GitHub Check: Test Flutter 3.38, Windows
- GitHub Check: Test Flutter 3.38, Ubuntu
🔇 Additional comments (1)
.gitattributes (1)
1-15: ✓ Clean.gitattributessetup for line ending normalization.The file correctly enforces LF line endings across all key file types (Dart, YAML, Markdown, JSON, shell scripts, and generated mocks). The pattern ordering is sound—general patterns precede specific overrides—and the
text=autofallback is a sensible default for other files.
…atforms" This reverts commit ca49b3a.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
48-53: Review line ending normalization script for shell compatibility.The Windows line ending normalization uses
find ... -exec ... \;syntax which may have compatibility concerns depending on the shell environment. While the sed fallback is prudent, consider a more robust approach.The current script attempts dos2unix then falls back to sed. Consider this more robust alternative:
- - name: Normalize line endings in generated mock files (Windows) - if: matrix.os == 'windows-latest' - shell: bash - run: | - find packages/dart/test -name "*.mocks.dart" -type f -exec dos2unix {} \; 2>/dev/null || \ - find packages/dart/test -name "*.mocks.dart" -type f -exec sed -i 's/\r$//' {} \; + - name: Normalize line endings in generated mock files (Windows) + if: matrix.os == 'windows-latest' + shell: bash + run: | + find packages/dart/test -name "*.mocks.dart" -type f | while read file; do + dos2unix "$file" 2>/dev/null || sed -i 's/\r$//' "$file" + doneThis approach avoids potential shell quoting issues with
-execand provides clearer error handling.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci.yml(3 hunks)
🔇 Additional comments (2)
.github/workflows/ci.yml (2)
105-114: LGTM: Flutter setup logic correctly handles both beta and version-specific channels.The conditional setup steps properly distinguish between beta and stable Flutter versions, ensuring the correct installation method is used for each.
17-34: Cannot verify version policy alignment—next significant versions lack stable release dates.The Dart 3.10 and Flutter 3.38 versions were released on November 12, 2025 (just now). However, the review comment claims these versions reflect a "6 months after next significant version release" policy. This verification is inconclusive because:
- Dart 3.11: No stable release date announced (tentative only, expected ~3 months after 3.10 per cadence)
- Flutter 3.39: Still in beta/candidate state; no stable release date available
The minimum versions set in the CI cannot yet be validated against the stated 6-month post-release policy, since the subsequent versions required for that calculation do not have published release dates. The policy comment may reflect planned future alignment rather than current verification.
Recommendation: Verify with the PR author whether these versions were selected based on estimated release timelines or a different criterion, and confirm the VERSIONING_POLICY.md actually exists and documents this 6-month window.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci.yml(3 hunks)
🔇 Additional comments (3)
.github/workflows/ci.yml (3)
40-45: Verify Windows git configuration necessity.The post-checkout git reconfiguration using
core.autocrlf false,git rm --cached -r ., andgit reset --hardis a heavy-handed approach. While reasonable in a CI context with fresh checkouts, confirm this is the intended approach for normalizing line endings and that it won't interfere with subsequent steps. Consider whether pre-checkout configuration via action parameters would be cleaner if available.
22-34: Version matrix updates align with PR objectives.The Dart and Flutter matrices correctly reflect the new minimum versions (3.10.0 and 3.38.0 respectively), remove support for expired versions, maintain multi-platform coverage (Ubuntu, macOS, Windows), and include beta channel testing for early identification of breaking changes. Implementation is clear and well-structured.
Also applies to: 87-99
156-156: Node.js version 24 is appropriate, though not the absolute latest.As of November 2025, Node.js v24 is designated as Active LTS (Long-Term Support). While v25.2.1 is the latest Current release, v24 remains a supported, stable version suitable for production use in CI workflows. Using an LTS version is a common and valid practice. No update is required unless the project explicitly requires the latest release branch.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
.github/workflows/ci.yml (1)
17-18: Version support policy comments still reference incorrect timeframe.The comments state "6 months after next significant version release" but the PR objectives specify a "12-month upgrade window" after the next significant release. This should be updated for consistency across both Dart and Flutter policy references.
Apply this diff to update both sections:
- # Version Support Policy: 6 months after next significant version release + # Version Support Policy: 12 months after next significant version release # See VERSIONING_POLICY.md for full detailsThis applies to:
- Line 17 (Dart section)
- Line 82 (Flutter section)
Also applies to: 82-83
🧹 Nitpick comments (2)
packages/flutter/test/src/storage/core_store_directory_io_test.dart (2)
62-90: iOS migration test logic looks solid; typo in assertion reasonThe test correctly verifies that the old DB file is removed, the new directory is
libraryPath, and the copied file matches the original size; the revisednewDBFilePathconstruction at Line 83 is clear and idiomatic.Very minor: the failure reason at Line 89 says “coped db file”; consider changing to “copied db file” for clarity.
128-167: Non‑iOS platforms loop test correctly guards migration; consider isolating platform overrideUsing
TargetPlatform.values.toSet()..remove(TargetPlatform.iOS)(Lines 134–135) is a nice way to cover all non‑iOS platforms, and the assertions that the DB file remains unchanged anddbDirectory == applicationDocumentsPath(Lines 147–164) accurately reflect the intended behavior.One minor improvement to avoid leaking state into other tests: you could reset
debugDefaultTargetPlatformOverrideafter the loop, or register a teardown inside this test, for example:- () async { - final targetPlatforms = TargetPlatform.values.toSet(); + () async { + final targetPlatforms = TargetPlatform.values.toSet(); targetPlatforms.remove(TargetPlatform.iOS); @@ - for (final platform in targetPlatforms) { + addTearDown(() => debugDefaultTargetPlatformOverride = null); + + for (final platform in targetPlatforms) { debugDefaultTargetPlatformOverride = platform;Not required for correctness here, but it makes the test more self-contained.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
.github/workflows/ci.yml(3 hunks)packages/flutter/lib/parse_server_sdk_flutter.dart(2 hunks)packages/flutter/lib/src/push/parse_push.dart(2 hunks)packages/flutter/lib/src/storage/core_store_directory_io.dart(1 hunks)packages/flutter/lib/src/storage/core_store_sembast.dart(1 hunks)packages/flutter/lib/src/storage/core_store_shared_preferences.dart(1 hunks)packages/flutter/lib/src/utils/parse_live_grid.dart(3 hunks)packages/flutter/lib/src/utils/parse_live_list.dart(7 hunks)packages/flutter/test/parse_client_configuration_test.dart(1 hunks)packages/flutter/test/src/storage/core_store_directory_io_test.dart(5 hunks)
✅ Files skipped from review due to trivial changes (7)
- packages/flutter/test/parse_client_configuration_test.dart
- packages/flutter/lib/src/storage/core_store_directory_io.dart
- packages/flutter/lib/src/storage/core_store_shared_preferences.dart
- packages/flutter/lib/parse_server_sdk_flutter.dart
- packages/flutter/lib/src/push/parse_push.dart
- packages/flutter/lib/src/storage/core_store_sembast.dart
- packages/flutter/lib/src/utils/parse_live_grid.dart
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Test Flutter 3.38, macOS
- GitHub Check: Test Flutter beta
- GitHub Check: Test Flutter 3.38, Windows
- GitHub Check: Test Flutter 3.38, Ubuntu
🔇 Additional comments (11)
.github/workflows/ci.yml (5)
22-30: Dart version constraint updates align with PR objectives.The minimum Dart version is correctly raised to 3.10.0 across all platforms (Ubuntu, macOS, Windows), removing support for expired versions 3.2–3.9 as specified in the PR.
31-34: Beta channel addition for early breaking change detection.Adding the Dart beta channel to the test matrix is a good practice for identifying breaking changes early in the development cycle.
40-45: Windows git configuration for line ending handling.The new step configures git to handle line endings correctly on Windows, which prevents checkout-related issues on that platform. This is a reasonable addition to the CI pipeline.
87-95: Flutter version constraint updates align with PR objectives.The minimum Flutter version is correctly raised to 3.38.1 across all platforms (Ubuntu, macOS, Windows), removing support for expired versions 3.16–3.37 as specified in the PR.
96-99: Beta channel addition for early breaking change detection.Adding the Flutter beta channel to the test matrix is a good practice for identifying breaking changes early in the development cycle.
packages/flutter/lib/src/utils/parse_live_list.dart (3)
13-14: LGTM! Clean public API addition.The
DataGettertypedef is well-named, follows the existing pattern ofStreamGetter, and clearly represents an optional data loader for ParseLiveList elements.
221-229: Breaking change appropriately enforced.Making
childBuilderrequired is a breaking change, but it's justified since the widget cannot function without it (always invoked at line 301). All existing usages already provide this parameter with a fallback todefaultChildBuilder.
4-8: Consistent formatting improvements throughout.The multiline formatting applied to typedefs, function parameters, and constructor calls improves readability and aligns with modern Dart formatting conventions from the updated SDK versions.
Also applies to: 72-75, 112-115, 121-138, 184-208, 251-256, 261-264
packages/flutter/test/src/storage/core_store_directory_io_test.dart (3)
93-125: iOS “no source db in old dir” test is well‑structuredThis test cleanly captures the “no-op migration” scenario when the DB exists only in
LibraryDirectory: usingdbFileInNewPath(Lines 101–103, 105, 107–108) and asserting unchanged size and last-modified timestamp plusdbDirectory == libraryPath(Lines 115, 121, 123) is precise and non-flaky for this use case.No issues from my side.
182-185: Library DB helper path join is clear and consistentSwitching
create1MBParseDBFileInLibraryPath(Line 183) to a single-linepath.join(libraryPath, 'parse', 'parse.db')keeps behavior identical and improves readability relative to the previous multiline construction.Looks good.
217-220: applicationDocumentsPath formatting change is non-functionalThe multiline
path.joinforapplicationDocumentsPath(Lines 217–220) is purely stylistic and keeps the effective path unchanged while matching the surrounding style.No concerns here.
# [9.0.0](dart-8.0.2...dart-9.0.0) (2025-11-28) ### Features * Remove support for expired Dart and Flutter versions ([#1052](#1052)) ([dbeb5cb](dbeb5cb)) ### BREAKING CHANGES * This release removes support for Dart 3.2 - 3.9 and Flutter 3.16 - 3.37. These versions exceeded their 6-month support window after the next significant version release. The minimum required versions are now Dart 3.10 and Flutter 3.38. ([dbeb5cb](dbeb5cb))
|
🎉 This change has been released in version 9.0.0 |
# [10.0.0](flutter-9.0.0...flutter-10.0.0) (2025-11-28) ### Bug Fixes * `ParseXFile` uploads file with content-type `application/octet-stream` if not explicitly set ([#1048](#1048)) ([a47f2a0](a47f2a0)) * Add support for Dart 3.4, 3.5; remove support for Dart 3.0, 3.1 ([#1016](#1016)) ([a3449f4](a3449f4)) * HTTP client exception not handled properly resulting in incorrectly formatted error ([#1021](#1021)) ([4f20640](4f20640)) ### Features * Add client access via `ParseDioClient.client` and `ParseHTTPClient.client` ([#1025](#1025)) ([af14388](af14388)) * Remove support for expired Dart and Flutter versions ([#1052](#1052)) ([dbeb5cb](dbeb5cb)) ### BREAKING CHANGES * This release removes support for Dart 3.2 - 3.9 and Flutter 3.16 - 3.37. These versions exceeded their 6-month support window after the next significant version release. The minimum required versions are now Dart 3.10 and Flutter 3.38. ([dbeb5cb](dbeb5cb))
2 participants
Closes #968
Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.