* WIP * Move warning to validateConfig This only happens in setupTrackingContext outside of resolveConfig * Use original dynamic require approach in `validateConfig` The important thing is that this happens in Node-land only. It is outside of `resolveConfig` which is public and importable into user projects. That is the scenario that breaks because of static import hoisting. * Don’t reference process when it might be undefined The `resolveConfig` dep path is public which should not reference process. However, we have some behavior that changes based on env vars so we need to conditionalize it instead. * Update changelog * Formatting * More formatting * Update changelog --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Jonathan Reinink <jonathan@reinink.ca> |
||
|---|---|---|
| .. | ||
| cli | ||
| css | ||
| lib | ||
| oxide | ||
| postcss-plugins/nesting | ||
| public | ||
| util | ||
| cli-peer-dependencies.js | ||
| cli.js | ||
| corePlugins.js | ||
| featureFlags.js | ||
| index.js | ||
| plugin.js | ||
| processTailwindFeatures.js | ||