feat: Upgrade various dependencies and fix warnings

[mbfakourii]

New Pull Request Checklist

• I am not disclosing a vulnerability.
• I am creating this PR in reference to an issue.

Issue Description

All versions and packages have been updated to the latest version and warnings have been resolved

Closes: #821

Approach

n/a

TODOs before merging

• Add tests
• Add changes to documentation (guides, repository pages, in-code descriptions)
• A changelog entry

[parse-github-assistant]

Thanks for opening this pull request!

• 🎉 We are excited about your hands-on contribution!

[codecov]

Codecov Report

Patch coverage: 5.88% and project coverage change: -0.02 ⚠️

Comparison is base (dc00f63) 16.38% compared to head (9bb14dd) 16.36%.

❗ Current head 9bb14dd differs from pull request most recent head 47149ee. Consider uploading reports for the commit 47149ee to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #824      +/-   ##
==========================================
- Coverage   16.38%   16.36%   -0.02%     
==========================================
  Files          47       47              
  Lines        2899     2902       +3     
==========================================
  Hits          475      475              
- Misses       2424     2427       +3     

Impacted Files	Coverage Δ
packages/dart/lib/parse_server_sdk.dart	28.57% <0.00%> (ø)
packages/dart/lib/src/network/dio_adapter_io.dart	0.00% <0.00%> (ø)
...ackages/dart/lib/src/network/parse_dio_client.dart	0.00% <0.00%> (ø)
...ckages/dart/lib/src/network/parse_http_client.dart	5.12% <0.00%> (ø)
...ackages/dart/lib/src/network/parse_live_query.dart	0.00% <0.00%> (ø)
packages/dart/lib/src/objects/parse_object.dart	14.95% <0.00%> (ø)
packages/dart/lib/src/objects/parse_user.dart	0.00% <0.00%> (ø)
packages/dart/lib/src/utils/parse_live_list.dart	0.00% <0.00%> (ø)
packages/dart/lib/src/network/parse_query.dart	22.31% <33.33%> (ø)
...b/src/objects/response/parse_response_builder.dart	37.50% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[mbfakourii]

@mtrezza
I updated and tested the packages, but CI is trying to use old packages!

In the Flutter package in this line, it uses the internal Dart package, which runs into problems because it uses new packages.

[mtrezza]

Why is the CI trying to use old pkgs?

[mbfakourii]

Why is the CI trying to use old pkgs?

For example, the Dart package uses dio: ^5.0.0, but the Flutter package uses dio: ^4.0.6, and we also use the parse_server_sdk: ^3.1.13 package, and this version uses dio: ^4.0.6. They have conflict. In CI, which is in this section, it uses parse_server_sdk at the local level and it is completely in the configuration.

[mbfakourii]

My suggestion is to first give a new version in the Dart version with dio: ^5.0.0 and then give this new version for the Flutter version. Regardless of CI errors

[mtrezza]

This is how we'd usually do it, as you described:

1. Release dart with upgrade to dio 5
2. Release flutter with upgrade to dio 5 and upgrade to the new dart release with dio 5

That should work fine. The question is why do we need the script that uses the local version of dart?
I imagine the script is for developing and testing changes locally that span across dart and flutter. But on GitHub in the CI I think that script should never run because a PR and its CI should only look at an individual release which can either be a dart or a flutter release, never both.

For example, if a new feature requires changes in dart and flutter, both changes can be developed locally. The developer wants to run tests locally using the script. Then a PR needs to be opened for dart, and a separate PR for flutter. In both PRs the script should not run in the GitHub CI.

So the solution could be to never run the script in the CI but provide it for the developer to manually run locally. Where is that script called?

[mbfakourii]

This is how we'd usually do it, as you described:

1. Release dart with upgrade to dio 5
2. Release flutter with upgrade to dio 5 and upgrade to the new dart release with dio 5

That should work fine. The question is why do we need the script that uses the local version of dart? I imagine the script is for developing and testing changes locally that span across dart and flutter. But on GitHub in the CI I think that script should never run because a PR and its CI should only look at an individual release which can either be a dart or a flutter release, never both.

For example, if a new feature requires changes in dart and flutter, both changes can be developed locally. The developer wants to run tests locally using the script. Then a PR needs to be opened for dart, and a separate PR for flutter. In both PRs the script should not run in the GitHub CI.

So the solution could be to never run the script in the CI but provide it for the developer to manually run locally. Where is that script called?

I agree with you, there should not be two ways, In my opinion too, this should be left to the developer

In this script, in line 9, the library corresponding to the pubdev version is deleted and in line 10, the local library is connected, which will check the local version

[mbfakourii]

I bumped the Dart version, I think it is ready for merge
After merge, I will increase the flutter version in another PR

[mtrezza]

Could you take a look at #831? I've removed the script from the CI so if we merge that first, the tests should pass in this PR I guess.

[mtrezza]

The coverage test is failing here. I think there is an issue in the CI, I'll take a look...

[mtrezza]

Codecov is failing due to lower coverage it seems. We can still merge I guess.

• Bumped version to 4.0.0 due to breaking change with dio 5.x upgrade
• Added breaking change note to changelog

There are some flutter changes left in:

• packages/flutter/lib/src/utils/parse_live_list.dart
• packages/flutter/lib/src/utils/parse_live_grid.dart
• packages/flutter/example_livelist/lib/main.dart

Could you revert these, so we can merge and release the dart package?

[mbfakourii]

@mtrezza
Do you think it is ready for merge?

[mtrezza]

I think we can, I was a bit hesitant because we have 2 packages that we - until now - always have released when the commit was made on that specific package. Now we're making dart commits while flutter hasn't been released yet. It's a change of process, so I was worried about the version tags, etc. But I think it should be fine, do you see any concerns?

[Nidal-Bakir]

I was a bit hesitant because we have 2 packages that we - until now - always have released when the commit was made on that specific package

why not when a tag is created?

I have a package that gets published automatically when I create a tag for a commit.

My publish.yml

name: Publish to pub.dev

on:
  push:
    tags:
      - "v[0-9]+.[0-9]+.[0-9]+*"

jobs:
  publish:
    runs-on: ubuntu-latest

    permissions:
      id-token: write
      contents: write

    steps:
      - name: 📚 Git checkout
        uses: actions/checkout@v3

      - name: 🎯 Setup Dart
        uses: dart-lang/setup-dart@v1

      - name: 📦 Install dependencies
        run: dart pub get

      - name: 🚀 publish
        run: dart pub publish --force

      - name: 🚀 Create release from tag for github releases
        uses: ncipollo/[email protected]
        with:
          tag: ${{ github.ref_name }}

[Nidal-Bakir]

We can modify my publish.yml to fit this project

[mbfakourii]

I think we can, I was a bit hesitant because we have 2 packages that we - until now - always have released when the commit was made on that specific package. Now we're making dart commits while flutter hasn't been released yet. It's a change of process, so I was worried about the version tags, etc. But I think it should be fine, do you see any concerns?

I don't think so, because the Flutter version will be released after the Dart version, so there is no need to worry

[mtrezza]

I have a package that gets published automatically when I create a tag for a commit.

We have that as well, see our workflow.

In the long run we want to automate releasing like we already do with other repos (e.g. Parse Server). Since this here is a monorepo it's more complicated. Looking forward to monorepo release automation, I had some concerns, but let's release this for now, I think we should be good.

[mtrezza]

Looks good!