-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use postcss.config.js when present #4411
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4411 +/- ##
==========================================
- Coverage 35.57% 35.52% -0.06%
==========================================
Files 557 558 +1
Lines 6732 6742 +10
Branches 884 885 +1
==========================================
Hits 2395 2395
- Misses 3877 3886 +9
- Partials 460 461 +1
Continue to review full report at Codecov.
|
}, | ||
options: postcssConfig | ||
? { | ||
postcssConfig, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should it be { ...postcssConfig }
?
I think will be better something like this:
postcssConfig || {
// flexbug blah blah
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the config would work without a spread operator, but adding it doesn't hurt anything, so I will 👍
I'm totally fine with that! I do my best to not subscribe to lint beliefs and simply adhere to the linting of the code base. I have seen @ndelangen express a favor towards ternaries when discussing short-circuits, so I did it that way; perhaps a lint rule is in order to prevent further confusion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was more about to simplify the readability. Maybe even worth to extract it to a func
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
simplify the readability
is subjective.
I think ternaries read fine, but most importantly this discussion shouldn't even happen. We should just have a lint rule to prevent bike-shedding. I want to do whatever the team wants to do here.
Doesn't look like ESLint has a rule to prevent this discussion aside from preventing ternaries at all. It'd be cool to see a prefer-short-circuit
lint rule which favors &&
or ||
instead of ternaries where one option is null
or undefined
Anywho... I'll go ahead and make both of those changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should have an example for this I think
} | ||
: { | ||
plugins: () => [ | ||
require('postcss-flexbugs-fixes'), // eslint-disable-line global-require |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that something won't work if this plugin will be missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plugins are currently available, correct? I didn't remove dependencies for that reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, should we somehow merge it to the user's config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I wouldn't do that. Either we give them a set of defaults, or they have full control. I'm not a fan of doing obscure things like providing a pair of plugins the user may or may not want if they have their own postcss config.
Agreed on needing an example. I'll add one and update docs as long as this is going in the right direction. |
Gonna wait on #4405 before I move forward. The only work left to be done will be to integrate with those changes + provide an example + update docs 👍 I'm prepared to make the moves at any moment in my work day. |
…/use-custom-postcss-config
Generated by 🚫 dangerJS |
|
||
export default function getStyleConfig(baseConfig) { | ||
// null if file is not found | ||
const customPostcssConfig = findUp.sync('postcss.config.js', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will be very nice if you could asyncify this... Need to add some additional await
s in the call chain though. Not critical one, bit since we already support async/await that be great =)
Suggested spot for documentation: Norbert spoke with me about creating an example folder for this, so I will 👍 Temporarily committed example to make it easier for people to try out themselves. In testing it locally, I run |
|
||
export default async function getStyleConfig(baseConfig) { | ||
// null if file is not found | ||
const customPostcssConfig = await findUp.sync('postcss.config.js', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should be just findUp(...)
without the sync
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ fixed
@ndelangen thoughts on deleting this branch PR and starting from the new API changes? |
Gonna take another stab at this in a different PR since direction has changed a bit |
Issue: #2455
What I did
find-up
to dependencies to search for the nearestpostcss.config.js
postcss.config.js
to determine postcss-loader options if present, maintain previous defaults if not.How to test
postcss-import
).Is this testable with Jest or Chromatic screenshots? Only if a custom serializer renders all styles.
Does this need a new example in the kitchen sink apps?
No.
Does this need an update to the documentation?
Yes. Describe that custom postcss.config.js should be handled just like custom babel configurations. Just wanted to ensure this is the correct direction before I add any changes.
If your answer is yes to any of these, please make sure to include it in your PR.
For maintainers only: Please tag your pull request with at least one of the following:
["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]