There’s some discussion of the reasoning in this thread and also here. There are a lot of potential footguns when building JUCE modules into library targets, and I haven’t been able to come up with a solution that’s safe and generally applicable. Shared libraries are especially difficult to get right, because some plugin hosts also use JUCE. If you build a plugin which depends on a JUCE shared library with public symbols, it’ll be very likely to crash hard in a host using a different JUCE version, because there will be multiple different versions of JUCE symbols all in the same process. These kinds of issues are especially insidious because they can appear to work most of the time, but then fail if a plugin is loaded in specific hosts.
It’s difficult to design for use-cases we don’t know about! For example, I don’t understand why a JuceHeader would be desirable for a library target. When consuming a library, generally I’d want to keep my includes as granular as possible, rather than including every symbol in that library everywhere. That being said, an approach like that mentioned here should result in a usable JuceHeader-less library target (although you’ll need to replace STATIC with SHARED and change the visibility settings so that you can actually pick up symbols from the library). And to reiterate, I’d strongly advise against using such a library in a plugin target.