chore: remove pubspec_overrides.yaml and pubspec_overrides.yaml.disabled #2262
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Remove and disable the local development mode completely.
The file
pubspec_overrides.yaml
exist so we can override the dependencies to use the local ones instead from pub.devWe usually don't want that in production, so it's only during development to allow contributors to focus on the changes instead having to update the minimum change of
flutter_quill
by first introducing the internal breaking changes, upload a version so we can use it in the version after it as a minimum forflutter_quill_extensions
(See 10.7.2) as an example.Contributors had to include the
dependency_overrides
and then remove it before pushing a commit, sometimes they push a commit to test the changes in CI. I introduced thepubspec_overrides.yaml.disabled
which will be ignored by pub.dev (as it usespubspec_overrides.yaml
instead) and two scripts which will createpubspec_overrides.yaml
files and delete them (which is ignored in.gitignore
).I don't see a strong reason for this feature, if we need to fix something we should do it manually and ensure a compatible minimum version requirement, we also usually test using the example app so it's usually enough to have it there.
Also, I see some other issues of having only one version for all packages,
dart_quill_delta
should have its own version separated fromflutter_quill
. Same toflutter_quill_test
as it didn't introduce any changes. Theflutter_quill
andflutter_quill_extensions
might or might not require only one version.CHANGELOG.md
which is not very organized (see Improve quality and format of CHANGELOG.md #2211).flutter_quill
andflutter_quill_extensions
. When a new API introduced influtter_quill
and it's needed influtter_quill_extensions
, with our current workflow, we have to release it in backward compatible way even if it's an internal API first, once we have the new version offlutter_quill
, we need another release that increases the minimum version offlutter_quill
influtter_quill_extensions
flutter_quill
andflutter_quill_extensions
, when a breaking change is introduced, users expect improvements and new features to the final product, so we should enhanceflutter_quill_extensions
and once there is a strong reason to introduce a breaking change by fixing issues, introducing features and more tests then we will probably introduce it, fixing it requires a separate package offlutter_quill_extensions
and that's not a priority at the moment.quill_native_integration
with its own packages (quill_native_integration_platform_interface
,quill_native_integration_web
,quill_native_integration_windows
etc...). See feat: Use quill_native_bridge as default impl in DefaultClipboardService, fix related bugs in the extensions package #2230 for more details.As for
quill_native_bridge
, I will also separate the version, I need to publish a new package and deprecate this, luckily it's already experimental and for internal use so shouldn't be a breaking change as we didn't expose the APIs of it yet (see #2230). The new package will probably bequill_native_integration
.Tip
This PR only removes thee local development mode and those two files in addition to their scripts and doesn't fix or change all of the points mentioned above. The publishing will still be the same.
Related Issues
Type of Change