Devtool_extension: Would it make sense to have the extension's sources directly in the devtool/extension folder?

[rrousselGit]

Hello!

Currently the recommendation seems to be to have:

my_package:
  lib/
  extension/devtool/
    config.yaml
    build/
my_package_extension/
  pubspec.yaml
  lib/

I was wondering if there would be any possible issue with instead having:

my_package:
  lib/
  extension/devtool/
    .pubignore
    config.yaml
    pubspec.yaml
    build/
    lib/

where .pubignore is:

lib/
test/
pubspec.yaml

This would be easier to manage as:

• there is no need to copy my_package_extension/build to my_package/extension/devtool/build
• it would be simpler for tools to catch when my_package needs to be re-released. Release tools could also more easily recreate that build directory (as they would have access to the source).

[kenzieschmoll]

This is an interesting proposal. @jonasfj what are your thoughts on this configuration? Would it be possible to have a .pubignore file that ignores everything except build/ and config.yaml, that way nothing else accidentally sneaks its way into the published package?

The one concern I have here is that it seems like it may be more likely that a package author publishes a non-release build of their extension because they do not have to run the build_and_copy command that ensures the build is done properly.

[rrousselGit]

On the flip side, pub publish could easily run flutter build --release in the devtool folder before publishing the packages.

I personally use a custom publish command in all of my projects, and was thinking about updating it to do exactly that if extension/devtool is detected.

[jonasfj]

.pubignore supports the same syntax as .gitignore, so you can ignore everything and then unignore a specific folder (I think).

Honestly, I would suggest including the sources for the flutter app, unless it's huge, just because it would make the app more complete.

On the flip side, pub publish could easily run flutter build --release in the devtool folder before publishing the packages.

Don't get me wrong I love this extension stuff, but the number of people who are going to publish extensions is always going to be a very small minority of the people who publish packages.

I don't think it makes sense to customize the pub tool for extensions. Even if, they are fairly trivial. It could make it a LOT harder to evolve the devtool extension format / features in the future.

I'd suggest to putting a script for publishing in tool/publish.dart or tool/publish.sh, and then recommend that people use that for publishing.

Or recommend that devtool extension authors add a dev_dependency on a package you own, and put utility functions into that package.

Example

• Create a package: devtools_extension containing:
  • bin/devtools_extension.dart such that it has following commands:
    • dart bin/devtools_extension.dart validate
    • dart bin/devtools_extension.dart build
    • dart bin/devtools_extension.dart publish
• Extension developers who add a dev_dependency on devtools_extension.
• Extension developers can now run: dart run devtools_extension valdiate|build|publish

That would be one way where, you can easily give commands and structure to extension authors.
But it might also be perfectly fine to just create a template and put a bash script in tool/publish.sh that ensures the correct build scripts are executed.

[rrousselGit]

I'm aware that modifying the pub commands isn't going to be that useful.
It's just about creating a convention so that tools can rely on it.

For example someone may want to write a reusable Github Action for continuous deployment of packages, and would like to support deploying packages with extensions too.

The various existing samples around setting up extensions would require extra configuration for such a Gtihub Action to know how to deploy packages with devtool extensions.
I wanted to challenge those samples to see if we could have something more universal

[jonasfj]

I drafted a proposal for something like local-hooks in dart-lang/pub#4058

I don't know if this is a good idea, maybe this proposal is too generic. Maybe, the whole concept is too complicated. Most packages probably won't need it.