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
Provide a pluggable method for asset transformation #101077
Comments
Some rough notes:
|
@jonahwilliams says he might be able to write a onepager on this. We talked some more this morning and agreed we don't need to make this work for the icon shaking, but it might help support some other features the tool has had requests for like platform specific assets. |
SGTM |
It would be great if we could make both the icon font transformer and the license file munger components that just plug into this more generic framework. |
one of these ways I tried to make this tractable was to massively simplify the scope of what we could run over. By just allowing asset -> asset transformations, we allow for a very simple API with almost no configuration required. We must avoid making a generic build system, otherwise we'd probably be better taking something off the shelf. These usually come with severe tradeoffs and don't work in the same out of the box way that Flutter does today. |
oh totally, i wasn't suggesting making a build system. the icon transformer is asset->asset, right? |
its asset + compiled dart kernel -> asset, which relies on const finder and some tricky assumptions about how and when tree shaking applies to Dart code. Potentially a better fit would be something like the shader features which use impellerc to do shader compilation. The complications there have to do with
|
Ah if you mean asset -> asset with literally no other inputs, not even inputs that would be the same for all assets, then yeah, the icon transformation doesn't fit either. A clean asset -> asset transformation with no dependencies at all is a very interesting subset of the problem space, because it can be parallelized very efficiently, so that makes sense to me. Shader compilation seems like it has the same kind of needs (i.e. additional build-wide information) as the icon transformation. |
Yeah, it has global configuration requirements, but it doesn't depend on the outputs of other build steps. So definitely a step in complexity from the asset -> asset transformations but not as complex as icons. |
Ah, fair. That distinction makes sense. |
@dnfield Do you recall where to find such requests? I'm interested in known potential use cases for asset transformation outside of easier use of |
It'd be cool if this feature provides a pluggable API that you can extend and run your own code. |
@christopherfujino @jonahwilliams @dnfield If this work is still up for grabs, I'm interested investigating if I can take on this "Good Starter Project" but would require some guidance as to what&where to read code pertaining to the enhancement discussed here. In particular, I'm keen on devising up a generic use case that would ideally be platform-independent. (@marandaneto use case is one such case I'd think could be catered for) |
The current scope of this feature is limited to pure asset-to-asset transformation, where "asset" refers to a file defined under |
Hi @sivang, thanks for your interest in contributing; however, I'm already working on this feature. |
Thanks @andrewkolos , I'm still interested in understanding the code behind this mechanism in the flutter build system, where to start reading? :) |
The tool already does transformation of icon fonts at build time.
It would be good to make an interface like that open and pluggable, so that packages external to the tool could decide to transform assets. For example,
package:vector_graphics
will want to transform SVG files into a different kind of file at build time by invoking a Dart program to process them.@christopherfujino @jonahwilliams for input
The text was updated successfully, but these errors were encountered: