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

Add helious/emotion-mirror link to Libraries #2983

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

helious
Copy link

@helious helious commented Feb 4, 2023

What:
I felt like I made a thing that is worth sharing to the Emotion community! I'd like to add https://github.com/helious/emotion-mirror to the Libraries links so others can get runtime linting via https://stylelint.io/ for their CSS-in-JS components. It's nice to get warnings when you have malformed CSS or want to set up a way to enforce some CSS standards for a repo.

Why:
The team I currently worked on were talking about leveraging template strings or opting for object syntax when using styled; we like how the template strings feel like writing CSS, but we also liked that security that we were setting valid CSS props with the object syntax. Alas, I saw that both approaches really miss out on validating the styles that are actually generated when using CSS-in-JS, leading to potential bugs from malformed CSS.

How:
So I set out on a journey to implement some sort of linting on CSS-in-JS's generated CSS. Opted to make this a plugin that could treeshake out and only run while code is in development. Wrapped styled with stylelint's bundled version so it could run in the browser. Grabs the output and runs it through stylelint when a styled component renders and present any warnings in the browser's console.

Checklist:

  • Documentation
  • Tests N/A
  • Code complete N/A
  • Changeset N/A

Would love anyone to test this out besides myself! Would love to see others gain value out of this. :)

@changeset-bot
Copy link

changeset-bot bot commented Feb 4, 2023

⚠️ No Changeset found

Latest commit: e9e54dd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

@codesandbox-ci
Copy link

codesandbox-ci bot commented Feb 4, 2023

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 e9e54dd:

Sandbox Source
Emotion Configuration

@Andarist
Copy link
Member

Andarist commented Feb 7, 2023

So I set out on a journey to implement some sort of linting on CSS-in-JS's generated CSS. Opted to make this a plugin that could treeshake out and only run while code is in development. Wrapped styled with stylelint's bundled version so it could run in the browser. Grabs the output and runs it through stylelint when a styled component renders and present any warnings in the browser's console.

You could also use MutationObservers and such and track what is being appended to the body and validate that. This way people wouldn't have to change all of their imports to use your wrapper.

@helious
Copy link
Author

helious commented Feb 8, 2023

@Andarist I gave it a shot, but you end up linting the compiled styles that emotion puts out (so with fallbacks, compressed, etc.) and you are no longer linting the styles that you write into your components. I see the value in offering a solution that can just be called once during App initialization, but it would be nice if we could capture something closer to what the developer is writing in that approach.

This way people wouldn't have to change all of their imports to use your wrapper.

I'm not sure how others have their code structured, but yea I agree finding and replacing the imports could be a chore.
I often utilize an "outerface" approach (or simple facade) for external libraries:

// src/styled.ts
import styled from '@emotion/styled';

export default styled;

// src/component/Foo.tsx
import React from 'react';
import styled from '../styled';

const Container = styled.div`
    padding: 20px;
`;

const Foo: React.FC = () => <Container>Foo</Container>;

export default Foo;

This way I'd only have to make an update to the external library in one spot. :)

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