refactor: Update dart dependencys

[mbfakourii]

Pull Request

• Report security issues confidentially.
• Any contribution is under this license.
• Link this pull request to an issue.

Issue

Update dart dependencys

Closes: #966

Approach

n/a

Tasks

• Add tests
• Add changes to documentation (guides, repository pages, code comments)

[parse-github-assistant]

Thanks for opening this pull request!

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (dc7e3d6) 39.63% compared to head (44bff2f) 39.60%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #967      +/-   ##
==========================================
- Coverage   39.63%   39.60%   -0.04%     
==========================================
  Files          60       60              
  Lines        3333     3333              
==========================================
- Hits         1321     1320       -1     
- Misses       2012     2013       +1     

see 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mbfakourii]

@mtrezza

Considering this ci error, I think it is better to stop supporting Dart below 3

Also, many of the new features are unusable and developers encounter conflicts and issues!

[mtrezza]

According to our support policy, dart 2.x will be supported until March 2024. What is the issue?

[mbfakourii]

According to our support policy, dart 2.x will be supported until March 2024. What is the issue?

We are unable to update the http package to a version above 1.

Because parse_server_sdk depends on http >=1.0.0 which requires SDK version >=3.0.0 <4.0.0, version solving failed.

[mtrezza]

I believe this is a special case because it's the first stable release 1.0.0, so the developers just decided to cut Dart 2.x support, which is fair enough. The issue is more on our side that we decided to use an unstable library (version 0.x). This library could have introduced breaking changes with any release, so we took some risk there. We should have looked for an alternative instead. That's a lesson for us when considering dependencies.

Under normal circumstances I don't think we've seen such a drastic drop for support, Dart 3 has been released just 4 months ago. Such a short forced upgrade cycle is unusual (they are more like years in most ecosystems) and would likely be challenging for developers, so I think our policy for 1 year support is still good.

I think our options are:

• a) Temporarily look for an alternative to the http library and maybe move to version 1.0.0 in May 2024 when we end support for Dart 2.19.
• b) Keep as is and maybe recommend developers to override the dependency in the meantime on their own risk.
• c) Introduce a new release branch so we have a separate SDK for Dart 2.x and 3.x. --> likely too much work.

[mbfakourii]

I believe this is a special case because it's the first stable release 1.0.0, so the developers just decided to cut Dart 2.x support, which is fair enough. The issue is more on our side that we decided to use an unstable library (version 0.x). This library could have introduced breaking changes with any release, so we took some risk there. We should have looked for an alternative instead. That's a lesson for us when considering dependencies.

Under normal circumstances I don't think we've seen such a drastic drop for support, Dart 3 has been released just 4 months ago. Such a short forced upgrade cycle is unusual (they are more like years in most ecosystems) and would likely be challenging for developers, so I think our policy for 1 year support is still good.

I think our options are:

• a) Temporarily look for an alternative to the http library and maybe move to version 1.0.0 in May 2024 when we end support for Dart 2.19.
• b) Keep as is and maybe recommend developers to override the dependency in the meantime on their own risk.
• c) Introduce a new release branch so we have a separate SDK for Dart 2.x and 3.x. --> likely too much work.

I think option b is better.

There's a method called dependency_overrides that allows us to temporarily override all references to a dependency.

Regarding the http library, I believe it was the first library to handle server requests in Dart, and we were forced to use it at that time. Currently, we not only use http but also support Dio.

[mtrezza]

Currently, we not only use http but also support Dio.

Can we remove it then?

[mbfakourii]

Currently, we not only use http but also support Dio.

Can we remove it then?

No, the http package is one of the main foundations of our package

[mtrezza]

Apologies, I've misread your comment.

[mbfakourii]

Apologies, I've misread your comment.

I'm sorry for my language. English is not my native language, but I am improving it. Please let me know if there is anything wrong. ❤️

Regarding this PR, I think it is better to wait for the result of Dart support policy.

[mbfakourii]

I think there is no need for this PR anymore