[Feature Request] Add fastInit to HiltExtension

[AlexanderGH]

There are cases where I want to debug things like "what is the path from injector to certain injectee" or "what is the set of classes causing an injection cycle" and with fastInit, it's hard/impossible to click through (from Android Studio) to the switching provider impls.

Simple adding dagger.fastInit=disabled to the ksp config doesn't seem to work (i'm guessing maybe the fastinit config in the javacompile task isn't overridden). Would it be possible to drive fastinit through the HiltExtension (default = true)?

[bcorso]

Yeah, this was brought up a while ago but never implemented -- we should make the ksp flag take precedence over the HiltAndroidPlugin's default behavior. At the time, I was talking with @danysantiago about this but I can't remember if this was an issue with timing (e.g. we don't have access to the user's flags at the time we set the defaults in HiltAndroidPlugin) or if we just never got around to it. Either way, if it's not possible I'm also open to adding the ability to control it via the HiltExtension.

Unfortunately, I'm unlikely to look at this quickly due to other higher priority issues but more than happy to take contributions here.

[AlexanderGH]

As a sidenote, i'm not sure if any of the ksp args seem to work. I haven't confirmed explicitly but I definitely banged my head against the wall with at least the full SPI graph param.

Would it be possible to expose a way to control all hil/dagger params like this via the hilt plugin so that it's guaranteed there are not any ordering/precedence issues between ksp and the hilt plugin?

[bcorso]

Would it be possible to expose a way to control all hil/dagger params like this via the hilt plugin so that it's guaranteed there are not any ordering/precedence issues between ksp and the hilt plugin?

Yes, open to contributions here as well.

[trexem]

Hi @AlexanderGH , I'm currently working on a PR to address this. We're looking at adding a proper DSL to the Hilt Gradle Plugin (e.g., hilt { enableFastInit = true }).

To ensure we build the right thing, could you share a bit more about your use case? Specifically:

• Scope: Are you looking to toggle this for a single module, or are you looking for a way to enable it globally across a multi-module project?

• Workflow: Is this something you want to "set and forget" in your build.gradle, or do you need to toggle it frequently via the command line (e.g., for CI or debugging)?

[AlexanderGH]

tl;dr dealer's choice/whatever makes the most sense and matches google3 capabilities.

Scope:

• I'd do whatever makes the most sense and is simpler. I'm not familiar with what changed in Hilt since it was open sourced, but I thought most of the changes are at the build root where all the switching providers are generated. If there are meaningful changes in each module though I'd also just have the option there for consistency/simplicity of not needing different DSLs for application/test vs library.
• I'm mostly hoping for whatever the ksp param configs are to be set in a more reliable way. If the behavior I assume from pre-open-sourcing is the same, just the root appmodule is fine.
• If the switching providers are all over the modules, then i'd want it to be global.

Workflow:

• For fastInit, this would be something that's generally set and forgotten as it is today, though occasionally (maybe 2x a year) it would be useful to see the generated providers to debug some weird issue.
• I'm equally interested in all other Hilt properties, e.g. for the dagger SPI, not just fast init. I suuspect there's some weird issue where maybe the ksp path doesn't work or hard to confirm if it works and a explicit dsl would delegate getting it right to the Hilt plugin as opposed to me debugging AGP/Hilt.

[bcorso]

I'm not familiar with what changed in Hilt since it was open sourced, but I thought most of the changes are at the build root where all the switching providers are generated.

Yes, for fastInit in particular it really only matters in the modules where your components are defined (which for hilt is in the application). This is mostly why we're a little hesitant to add the option to the hilt extension because typically you just want it to be on our off for an entire build, and I'm not sure it makes sense to control at an individual module level. In addition, it can be error-prone when users think they've enabled/disabled fastInit but turns out they applied it to the wrong place.

Thus, our initial plan is to

• Allow overriding the default (fastInit=enabled) only via the command line
• Throwing an error if you try to disable it by setting annotationProcessorOptions (as you mentioned in your original post, this is currently ignored so throwing an error will just let users know that the option isn't actually doing anything).

@AlexanderGH Will this plan work for you?

[AlexanderGH]

Yep. That works for fastInit since we basically would only ever disable it for one-off local debugging.

For other KSP configs where the default is not what we want, e.g. these:

    arg("dagger.fullBindingGraphValidation", "ERROR")
    arg("dagger.ignoreProvisionKeyWildcards", "ENABLED")

(and also some full graph SPI one which i currently removed due to other dagger or gradle issues but want to re-enable)
Ideally there was a reliable/guaranteed way to confirm those work and aren't ignored.