Add the shared_preferences_tools extension to the shared_preferences package

[kenzieschmoll]

A DevTools extension for the shared_preferences package has been published as package:shared_preferences_tools: https://pub.dev/packages/shared_preferences_tools.

To bring the most value to users of the shared_preferences package, we should consider moving this extension into the package it is intended to be used with (package:shared_preferences).

Accompanying issue on the shared_preferences_tools repo: adsonpleal/shared_preferences_tools#2

[stuartmorgan]

I'm not very familiar with the extension structure; I assume this would be both https://github.com/adsonpleal/shared_preferences_tools/tree/main/packages/shared_preferences_tools and https://github.com/adsonpleal/shared_preferences_tools/tree/main/packages/shared_preferences_tools_devtools_extension? The latter has some significant third-party dependencies.

[kenzieschmoll]

DevTools extension docs: https://pub.dev/packages/devtools_extensions.

For a package to provide a DevTools extension, it needs the following content:

package_foo/
  extension/
    devtools/
      build/  # precompiled assets of the extension flutter web app
      config.yaml. # configuration file that tells DevTools how to display the extension

So for shared_preferences to provide a DevTools extension, only the pre-compiled Flutter web app for (https://github.com/adsonpleal/shared_preferences_tools/tree/main/packages/shared_preferences_tools_devtools_extension) would need to be included in shared_preferences/extension/devtools/build, not the source code itself. That being said, we would still want to review the code before shipping the extension with a first party package.

Developing the source code outside of the flutter/packages repo could make this a bit odd to maintain, so we may want to bring the source code into this repo as well, even if we don't publish it or roll it into google3.

Is the concern about bringing new dependencies into the Flutter SDK that are not allowed? This wouldn't be an issue since shared_preferences_tools_devtools_extension would not be published nor depended upon by any other package.

[stuartmorgan]

Developing the source code outside of the flutter/packages repo could make this a bit odd to maintain, so we may want to bring the source code into this repo as well, even if we don't publish it or roll it into google3.

I would definitely not want to be shipping precompiled output of code that we don't control. That has significant chain of trust and maintainability issues.

Is the concern about bringing new dependencies into the Flutter SDK that are not allowed? This wouldn't be an issue since shared_preferences_tools_devtools_extension would not be published nor depended upon by any other package.

https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#dependencies summarizes the concerns with dependencies in flutter/packages.

[stuartmorgan]

I think the next steps here would be:

1. confirmation that the author would be interested in doing this, and
2. if so, a discussion of how plausible removing some third-party dependencies would be.

[github-actions]

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
If you find this problem please file a new issue with the same description, what happens, logs and the output of 'flutter doctor -v'. All system setups can be slightly different so it's always better to open new issues and reference the related ones.
Thanks for your contribution.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

[kenzieschmoll]

Re-opening this issue after this comment from the package author @adsonpleal adsonpleal/shared_preferences_tools#2 (comment).

@adsonpleal I think the next steps would be to see if you can remove the third party dependencies that are a concern, and post back here with the list of dependencies that would still be in use (you can just copy and paste the pubspec). @stuartmorgan does that sound good?

[stuartmorgan]

Sounds good.

[adsonpleal]

@stuartmorgan and @kenzieschmoll

I can remove all packages that are not from the dart/flutter team. I'd need to keep only:

dependencies:
  devtools_extensions: ^0.0.10
  devtools_app_shared: ^0.0.5
  vm_service: ^13.0.0
  
dev_dependencies:
  mockito: ^5.4.4

If I could keep riverpod the code would be cleaner, though.

[stuartmorgan]

If I could keep riverpod the code would be cleaner, though.

We should not add a dependency on riverpod to flutter/packages, both for all the reasons listed in the policy link above, and because from a long-term repository maintenance standpoint it's undesirable to have a precedent that we allow dependencies on the popular-state-manager-du-jour, since it seems like there's a new most popular one every year or so, which means we would very likely end up in a state where we accumulated dependencies on more and more of them over time.

[adsonpleal]

No worries, I can just use flutter/dart packages. Soon I'll open a PR and ping you and @kenzieschmoll.

[adsonpleal]

@kenzieschmoll I've finished the work of adding the extension directly to the shared_preferences package. I'm just doing some small polishings and I'll open a PR.

But I think I've found a bug for web targets, I've opened a new issue in the devtools repo.