The decision on which step(s) to run is a concern of the make phase, not the configure phase, so trying to discover which step the user intended to run inside your build function is almost certainly the wrong approach. Right now you could technically cheat by taking a peek at the argv for the process, but this is a hack (and it also won’t work for dependencies). In the future when the build process is properly isolated into these two configure and make phases, it wouldn’t surprise me if step information is made completely unavailable to the configure phase and that sequential invocations like zig build shaders followed by zig build test will use the same cached configure phase result.
However, the underlying problem that there’s no way to conditionally resolve lazy dependencies is in my eyes a pretty serious design flaw in the build system. If you ask me it shouldn’t be up to the build function to imperatively resolve lazy dependencies, the result of calling b.dependency("foo", .{}).module("bar") should be a lazy by default, and it should only be when the make phase detects that a specified step requires the dependency to be made available that the package is fetched (I’ve written some more on this problem in the past).
But even if the laziness problem mentioned above is addressed, when it comes to lazyImport, where you need the dependency to be available immediately at the time the configure phase code is compiled (so that you code can call its exported functions, etc.), I don’t think there’s any good and clean solution. For that style of package, splitting it up into a “thin” non-lazy part that’s just a small build.zig with some exported functions and having it wrap the “fat” lazy part as a separate package containing all the binaries and other bloat will probably be the most pragmatic approach.