feat: support caching context with options as object#12
Conversation
src/lib/setupContext.js
Outdated
| } | ||
|
|
||
| let configPathCache = new LRU({ maxSize: 100 }) | ||
| let lastTailwindConfigHash = null |
There was a problem hiding this comment.
I don't think it's safe to store this globally, there can be multiple Tailwind builds happening at the same time in one process (like someone compiling 3 Tailwind configs in one webpack config) so you can never assume there is only one Tailwind config file unfortunately. This probably needs to be scoped by CSS file that triggered the build
There was a problem hiding this comment.
What about exposing a key to specify a source?
The default value would be the path and shall be specified as well has hash for cache optimisation.
This mostly improve the programmatic usage and portability of Tailwind JIT.
There was a problem hiding this comment.
Actually, it is the hash of tailwind config object, not file and regardless contextMap is already in the shared state keyed by sourcePath. But I see your point. I guess then we can use cacheGroup key that differs for each build and if does not exists not caching object.
There was a problem hiding this comment.
@adamwathan Last changes are using separate _cacheKey and _cacheValue for object config. With multi config case, one can use different key.
Caching behavior is opt-in and we can mention this in the docs or just left for advanced usage
adamwathan
force-pushed
the
main
branch
2 times, most recently
from
f79559e to
989bb37
Compare
|
Still planning to look at this, sorry for the delay! I definitely think it makes perfect sense that we would support providing the hash from the outside for people using objects instead of files as a perf optimization 👍 |
3 participants
This PR allows external tooling like nuxt to provide a generated hash in options (passed as object) to reuse context