Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rrousselGit opened this issue Oct 26, 2023 · 7 comments
Labels
devtools extensions Issues related to DevTools extensions

Comments

@rrousselGit
Copy link
Contributor

rrousselGit commented Oct 26, 2023

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
Copy link
Member

kenzieschmoll commented Oct 26, 2023

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.

@kenzieschmoll kenzieschmoll added the devtools extensions Issues related to DevTools extensions label Oct 26, 2023
@rrousselGit
Copy link
Contributor Author

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
Copy link
Member

jonasfj commented Nov 27, 2023

.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
Copy link
Contributor Author

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
Copy link
Member

jonasfj commented Nov 28, 2023

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.

@elliette
Copy link
Member

I'm going to close this in favor of @jonasfj's proposal in dart-lang/pub#4058. @rrousselGit feel free to re-open if this isn't what you are looking for. Thanks!

@jonasfj
Copy link
Member

jonasfj commented Jul 19, 2024

To be clear, I don't actually think there is anything stopping anyone from putting sources into extension/devtool/.

Maybe, one would have to make some custom scripts, but as long as the prebuilt extension is in extension/devtool/build/ -- how it gets there is probably up to you.

Our documentation, templates and tools might suggest a certain layout, but if something else works better in your case, who is going to stop you? 🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devtools extensions Issues related to DevTools extensions
Projects
None yet
Development

No branches or pull requests

4 participants