-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Run tests without optimization #14704
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
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
9ff2d99 to
5e26aec
Compare
639407d to
f08b1e7
Compare
| } | ||
|
|
||
| export async function run(candidates: string[]) { | ||
| export async function run(candidates: string[], { optimize = true } = {}) { |
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.
Not a big fan of having to add an object with optimize to every call site. How do you feel about this?
I’m wondering if we:
- Should make this the default (or is the number of
run()calls that do needoptimize: trueeven larger than this subset? - Should instead add a second
runOptimizedexport instead of adding a boolean variable?
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.
Also not a fan but not enough to really care. I think unoptimized is not the default. Pretty sure more tests require an optimized CSS result than not but I don't have a good idea of what the function should be called.
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.
Funny thing is, I did use a new method initially (14817cb) but run vs runOptimized or vs build all felt wrong, so did a fallback here because typically you run it without.
You could argue that we just don't run the tests through Lightning CSS (which will make the tests bigger but faster).
71c24fe to
5120b3b
Compare
13dd01e to
8fd45ba
Compare
6aa4ed3 to
7b0465b
Compare
8fd45ba to
ef7332a
Compare
5e4504d to
8d48594
Compare
ef7332a to
4055bb9
Compare
If we generate something incorrect, then Lightning CSS will throw it away which could result in the fact that we generate something wrong but don't know about it because of Lightning CSS. In a lot of tests we know that nothing should be generated, so running an optimization step is not required.
The optimization happens by default, but for the cases where we know we don't need to optimize, we can pass in a flag.
4055bb9 to
d5599c9
Compare
|
Closing this, if we want this we can re-enable it later. |

This PR improves the tests by not running the optimization step (via Lightning CSS) in places where we know that nothing should be generated.
In fact, if we generate invalid CSS where we expected that nothing was being generated, then Lightning CSS will throw the CSS out. This means that we have a bug somewhere in our code, and we should fix it but we don't know about it.
Bonus points: this improves the performance of the tests a tiny bit.