Skip to content
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

Merged
merged 11 commits into from Jan 5, 2020
Merged

Optimize Babel output a little bit #1656

merged 11 commits into from Jan 5, 2020

Conversation

Andarist
Copy link
Member

No description provided.

@changeset-bot
Copy link

changeset-bot bot commented Nov 27, 2019

🦋 Changeset is good to go

Latest 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

@codesandbox-ci
Copy link

codesandbox-ci bot commented Nov 27, 2019

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:

Sandbox Source
Emotion Configuration

@codecov
Copy link

codecov bot commented Nov 28, 2019

Codecov Report

Merging #1656 into next will decrease coverage by 0.08%.
The diff coverage is 92.85%.

Impacted Files Coverage Δ
packages/babel-plugin-emotion/src/utils/label.js 98.11% <100%> (ø) ⬆️
...bel-plugin-emotion/src/utils/get-styled-options.js 100% <100%> (ø) ⬆️
...tion/src/utils/transform-expression-with-styles.js 100% <100%> (ø) ⬆️
packages/utils/src/index.js 100% <100%> (ø) ⬆️
packages/babel-plugin-emotion/src/index.js 92.04% <50%> (-2.01%) ⬇️
packages/babel-plugin-emotion/src/utils/strings.js 96.66% <94.11%> (+1.42%) ⬆️

Copy link
Member

@emmatown emmatown left a 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

@Andarist
Copy link
Member Author

Andarist commented Dec 7, 2019

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 autoLabel: true (not sure actually if it's true right now, but we could make it so).

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?

@Andarist
Copy link
Member Author

@mitchellhamilton any more thoughts on this one? How I should proceed with this?

@emmatown
Copy link
Member

always, never and auto sounds good to me

@Andarist
Copy link
Member Author

SoautoLabel would become such enum rather than a simple boolean, right? What should be the default? I would vote on "auto"

@emmatown
Copy link
Member

Agreed

@Andarist Andarist force-pushed the optimize-babel-output branch 3 times, most recently from 4f29478 to caf9d21 Compare December 18, 2019 22:38
@Andarist
Copy link
Member Author

@mitchellhamilton could you review the code & existing tests? Once approved I'm going to adjust docs, add few simple explicit tests for possible autoLabel values and add a changeset

Copy link
Member

@emmatown emmatown left a 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: *) => {
Copy link
Member

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?

Copy link
Member Author

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:

appendStringToArguments(path, labelString, t)

both are very similar though so probably this could be unified somehow

Copy link
Member

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

Copy link
Member Author

@Andarist Andarist Jan 1, 2020

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.

@Andarist
Copy link
Member Author

Had an idea: Rename auto to dev because auto could really mean anything

Maybe "dev-only"? It would be a little bit more descriptive

@emmatown
Copy link
Member

Maybe "dev-only"? It would be a little bit more descriptive

SGTM

@Andarist
Copy link
Member Author

Andarist commented Jan 1, 2020

I believe this is now ready to be merged, there are new tests, changesets, and updated docs.

@emmatown emmatown merged commit c7850e6 into next Jan 5, 2020
@emmatown emmatown deleted the optimize-babel-output branch January 5, 2020 00:22
louisgv pushed a commit to louisgv/emotion that referenced this pull request Sep 6, 2020
* 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
@github-actions github-actions bot mentioned this pull request Nov 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants