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

[1.0] When using gatsby-plugin-sass final output CSS isn't run through autoprefixer #1347

Closed
levibuzolic opened this issue Jul 3, 2017 · 13 comments

Comments

@levibuzolic
Copy link
Contributor

levibuzolic commented Jul 3, 2017

If using gatsby-plugin-sass you don't get any vendor prefixes applied to your output CSS (in both development and production builds).

I'm wondering if maybe autoprefixer should be run as the final loader for CSS files regardless of other loaders so that the browserlist is always used.

Autoprefixer works when using gatsby-plugin-postcss-sass -- which makes sense, however there are some issues with gatsby-plugin-postcss-sass that I'm still investigating.

@KyleAMathews
Copy link
Contributor

Is this still an issue?

@kriim
Copy link

kriim commented Jan 12, 2018

Using Gatsby 1.9.149 and gatsby-plugin-sass 1.0.14 this was still an issue for me.

I managed to fix it by modifying the Webpack config like proposed in #318.

@KyleAMathews
Copy link
Contributor

@kriim would you like to put together a PR for the sass plugin so it works out of the box?

@kriim
Copy link

kriim commented Jan 15, 2018

So would you be fine if gatsby-plugin-sass always applied vendor prefixes using postcss and added sourcemaps for the develop stage by default? That would be at least my preferred default behavior.

The point of having gatsby-plugin-postcss-sass is to have the ability to pass in additional postcss plugins I guess?

@KyleAMathews
Copy link
Contributor

@kriim that'd make sense to me.

@scottyeck that was the original reason right for gatsby-plugin-postcss-sass? Any reason not to just move that functionality into core?

@kriim
Copy link

kriim commented Jan 15, 2018

Moving that into the default plugin would make sense to me too. It was a little confusing for me in the first place that there are two plugins.

@kripod
Copy link
Contributor

kripod commented Feb 12, 2018

Are there any updates regarding this issue? What should be done until a proper fix is available?

@m-allanson
Copy link
Contributor

@kripod It sounds like this is the suggested workaround for now: #318 (comment). Those changes would go in your local gatsby-node.js file, the docs on custom webpack configs have some more info on that.

@kripod
Copy link
Contributor

kripod commented Feb 13, 2018

@KyleAMathews I think it would definitely make sense to autoprefix every flavor of CSS in Gatsby v2.

@fk fk added the API/Plugins label Feb 13, 2018
@KyleAMathews
Copy link
Contributor

@kripod yeah agreed. @m-allanson mentioned he wanted to take a hard look at all our CSS setup and fix things up.

@kripod
Copy link
Contributor

kripod commented Mar 18, 2018

I tried gatsby-plugin-postcss-sass, but enabling it caused weird errors (which I cannot detail right now).

Is there any chance that autoprefixing SCSS will be effortless in the near future?

@dustinhorton
Copy link
Contributor

This is also an issue in gatsby-plugin-postcss-sass, see my issue @ #4535 for a repro repo.

@Chuloo
Copy link
Contributor

Chuloo commented Aug 3, 2018

Looked through this with @m-allanson and the issue has been resolved in v2.

Closing this now, please make sure to update to the latest Gatsby version and check if that solves the issue. 👍 Here's the migration doc from v1 to v2 if that helps. 😄

@Chuloo Chuloo closed this as completed Aug 3, 2018
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

No branches or pull requests

8 participants