Should locked apps omit triggerless components?

[tschneidereit]

When using a locally-developed component as a dependency for another component, it can be very useful to declare both components in spin.toml: that way, spin {build, watch} will ensure that both are (re-)built, instead of having to manually build the dependency. That alternative would not really work for spin watch to begin with, I think.

The downside of this approach is that any component declared in the manifest will be included in the locked app, increasing the size of deployments accordingly.

AFAICT, these components are guaranteed to be dead weight: anything not associated with a trigger has no way to be invoked after deployment, after all.

I propose that we change the application loader to filter out any components that aren't used by a trigger instead, so they don't show up in deployments.

[itowlson]

To be clear, are you suggesting we remove:

• The JSON describing the un-triggered component; or
• The un-triggered component binary itself?

(Your mention of "increasing the size" makes me think you're proposing to remove the binary, as the size of the JSON is almost a rounding error in most cases, but I want to be sure!)

[tschneidereit]

That was unclear indeed. I care about the binary in particular, but I guess I mean both.

This makes me realize that there's a more general way to think about this: a locked app should (I think) ideally only contain things that could impact its runtime behavior, or are of interest as information about any aspects of the runtime behavior. (Plus information such as toolchain info, build IDs and what have you, of course.)

This issue as currently posed would then talk about one specific instance of data to be pruned.