-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Optimize Babel output a little bit #1656
Conversation
🦋 Changeset is good to goLatest commit: 87a07e5 We got this. 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 |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 87a07e5:
|
packages/babel-plugin-emotion/src/utils/transform-expression-with-styles.js
Show resolved
Hide resolved
packages/babel-plugin-emotion/src/utils/transform-expression-with-styles.js
Show resolved
Hide resolved
packages/babel-plugin-emotion/src/utils/transform-expression-with-styles.js
Outdated
Show resolved
Hide resolved
7d980ef
to
c8b7b04
Compare
c8b7b04
to
5e0346d
Compare
Codecov Report
|
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'd like to keep labels even in production because it's useful for some people to see them in production and if people really want to disable them in production, they can do autoLabel: false
The same thing can be said about the reverse - if you want to see them in production, you can do My main motivation here is to optimize the default output - I always thought emotion is a huge proponent of such an approach with various hacks in the codebase just to make the output smaller. I could live with this not being the default (as long as I can configure things how I like it - which is no labels in production). A problem in this particular case though is that we output opaque css objects with env check and what I put in this PR is my desired output. You assume that the party which transpiles files is the very same one that consumes it - but there are other use cases as well, such as building a library in which I'd like this dual output with labels being visible only during development. So what I'm saying - maybe we need 3 values for autoLabel? true (always), false (never), 'auto'/undefined (with env checks). An additional question is - which one should be the default? |
@mitchellhamilton any more thoughts on this one? How I should proceed with this? |
always, never and auto sounds good to me |
So |
Agreed |
4f29478
to
caf9d21
Compare
@mitchellhamilton could you review the code & existing tests? Once approved I'm going to adjust docs, add few simple explicit tests for possible |
packages/babel-plugin-emotion/__tests__/__snapshots__/css-requires-options.js.snap
Outdated
Show resolved
Hide resolved
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.
Had an idea: Rename auto
to dev
because auto
could really mean anything
Also, needs a changeset
Other than that, LGTM
// @flow | ||
import { isTaggedTemplateExpressionTranspiledByTypeScript } from './checks' | ||
|
||
export const appendExpressionToArguments = (t: *, path: *, expression: *) => { |
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 this replaces appendStringToArguments
from src/utils/strings.js
so we could we delete appendStringToArguments
?
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.
appendStringToArguments
is still used here:
emotion/packages/babel-plugin-emotion/src/utils/transform-expression-with-styles.js
Line 149 in 3459ad7
appendStringToArguments(path, labelString, t) |
both are very similar though so probably this could be unified somehow
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.
Unifying them would probably be good. The main reason I brought this up though is that I saw that appendStringToArguments wasn't being run in the tests(https://codecov.io/gh/emotion-js/emotion/pull/1656/src/packages/babel-plugin-emotion/src/utils/strings.js) which probably isn't good
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've unified them, please take a look.
And the reason that function was not executed is that there were no tests for new autoLabel values (always and never), I've added them as well.
Maybe |
SGTM |
989b72c
to
87a07e5
Compare
I believe this is now ready to be merged, there are new tests, changesets, and updated docs. |
* Optimize Babel output a little bit * Fix label regression in dev nodes * Add `autoLabel` validation * Update more snapshots * Fix flow error * Rename auto to dev-only as autoLabel value * appendExpressionToArguments -> appendStringReturningExpressionToArguments * Add simple tests for new autoLabel values * Merge appendStringToArguments logic into appendStringReturningExpressionToArguments * Adjust docs about new autoLabel values * Add changeset
No description provided.