Include simple config objects when extracting static plugins#14699
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @philipp-spiess and the rest of your teammates on |
20d0c57 to
438c487
Compare
aab02ca to
09c0aab
Compare
09c0aab to
3c0528a
Compare
| } | ||
| `), | ||
| export default { | ||
| plugins: [falserequire('./plugin1')] |
There was a problem hiding this comment.
This reads like a typo rather than an intentional non-require call. Maybe like load or something?
There was a problem hiding this comment.
Haha I had it call frequire before and I actually went in and fixed it since I thought it's a typo 🤕 agree i will just call it load so there's absolutely no confusion.
|
Should we add integration tests for this? It feels wrong to me that I can't look at any tests and see "given this config file, the equivalent generated CSS file is this". Edit: Ah I think that's probably covered in the follow-up PR. |
Those are in the followup PR where the actual CSS changes happen: #14700 |
d775256 to
34fc9b0
Compare

This PR updates the
extractStaticPluginsfunction to also emit options as long as these are objects containing of onlystringandnumbervalues.While doing this I also cleaned up the
require('custom-plugin')detector to use a Tree-Sitter query instead of operating on the AST.Here are the two cases we considered:
The test plan also contains a number of scenarios that we do not want to migrate to CSS (because we do not have a CSS API we can use for e.g. nested objects). We do support all types that we also support in the CSS API.