Commits on Jan 6, 2022

1. improve extractCandidates …

   When we have a css rule that is defined as `.foo, .bar {}`, then we will
   crawl each selector and link it to the same node. This is useful because
   now our Map looks something like this:
   
   ```js
   Map(2) { 'foo' => Node {}, 'bar' => Node {} }
   ```
   
   This allows us to later on `@apply foo` or `@apply bar` and we can do a
   direct lookup for this "candidate".
   
   When we have css defined as `span {}`, then we consider this
   "non-ondemandable". This means that we will _always_ inject these rules
   into the `*` section and call it a day.
   
   However, it could happen that you have something like this: `span, .foo
   {}` up until now this was totally fine. It contains a non-ondemandable
   selector (`span`) and therefore we injected this into that `*` section.
   
   However, the issue occurs if you now try to `@apply foo`. Since we had
   an early return for this use case it didn't endup in our Map from above
   and now you get an error like:
   
   ```
   The `foo` class does not exist. If `foo` is a custom class, make sure it
   is defined within a `@layer` directive."
   ```
   
   So instead what we will do is keep track whether or not a css rule
   contains any on-demandable classes. If this is the case then we still
   generate it always by putting it in that `*` section. However, we will
   still register all on-demandable classes in our Map (in this case `.foo`).
   
   This allows us to `@apply foo` again!

   

   RobinMalfait committed Jan 6, 2022
   Copy the full SHA

   e848e1e View commit details

   Browse the repository at this point in the history

2. update changelog

   

   RobinMalfait committed Jan 6, 2022
   Copy the full SHA

   d0fc45c View commit details

   Browse the repository at this point in the history