Added configurable options to optimize CSS

[pancaspe87]

In the past it was decided to not let consumers "opt in" this behaviour ( see comment). However, we observe a mismatch between browser and SSR if the variable is not defined in one of those environments and extraction is enabled.

I set default value of optimizeCss to true so that existing consumers won't be affected by the change.

See https://github.com/atlassian-labs/compiled/issues/1263

Docs have been updated, see PR

Changes in test files to reflect the optimised value which is set by default. Consumers may need to update their tests too, if using toHaveCompiledCss to test CSS values that can be optimised

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: db23c8cb9fef59f935f8f5fff16b7282707c6110

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@compiled/babel-plugin	Patch
@compiled/css	Patch
@compiled/webpack-loader	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pancaspe87]

• [x] Update all failing tests due to expecting a different classes when applying all the CSS plugins. Eg

[at-nathan]

Thoughts on setting optimization to false for tests and storybook? Since optimization is not our code, there's no need to test it on our side IMO. It would make this PR smaller for sure :) Also when we write tests it would be helpful not to worry about getting the optimized style correct. It might also confuse new devs in the repo.

[pancaspe87]

Thoughts on setting optimization to false for tests and storybook? Since optimization is not our code, there's no need to test it on our side IMO. It would make this PR smaller for sure :) Also when we write tests it would be helpful not to worry about getting the optimized style correct. It might also confuse new devs in the repo.

Hey @at-nathan I think consumers can decide whether to opt out for their dev loop. In our case I would keep it as it is for consistency with the default behaviour; tests were updated only to reflect the new output now that we optimize everything.

@liamqma , @JakeLane thoughts?

[at-nathan]

Hey @at-nathan I think consumers can decide whether to opt out for their dev loop. In our case I would keep it as it is for consistency with the default behaviour; tests were updated only to reflect the new output now that we optimize everything.

@liamqma , @JakeLane thoughts?

@pancaspe87 Sorry I was saying we should set it to false for our tests. As @liamqma pointed out, it was confusing to see the optimized gradient output. It gave a false positive that the test was broken. I can foresee this happening in the future and it might make us assert the wrong thing and assume it's just an optimized value.