Consider not relying on previously defined mixin in file for "@apply"

[mtpc]

Currently @apply works by walking through all previously defined "mixins"[1] in the file before substituting the found ones, which constrains you to either only use one file, or to import all of your css in one place [2] before defining your custom utilities.
It of course won't work with popular css-in-js solutions [3] simply because the css fragment using @apply has no knowledge of tailwind's utilities, yielding the dreaded unable to find $SELECTOR error.
Importing them beforehand using @tailwind utilities everywhere is obviously not a solution because of duplication.

An idea would be to:

1. Check if the "mixin" has been defined before in the file/fragment, as usual
2. If none was found, try to get it from a global map of generated utilities
3. Throw if both of these steps yield nothing

---

[1] which are actually selectors, making me wonder why the mixin terminology was used
[2] #53 (comment)
[3] such as styled-component, emotionjs or even vue's "single file component" (#1 (comment))
They all are processed by postcss under the hood

[syropian]

I tried using https://github.com/ben-eb/postcss-discard-duplicates to discard the duplicate code created by @tailwind utilities; but unfortunately it just did not work for me at all. Has anyone else been able to get it to work?

The only other option would be to have the core include a "reverse parser", something that can take in a css class, and spit out a config key path. Probably not the easiest thing to do, but with it you could avoid including @tailwind utilities; all together when using @apply in something like a Vue single file component.

[syropian]

Follow up: I was able to dedupe the rules using https://github.com/ChristianMurphy/postcss-combine-duplicated-selectors, so that is an option.