Skip to content

Remove css-loader and style-loader from the postcss block#293

Merged
andywer merged 3 commits intoandywer:release-2.0from
marcofugaro:postcss-refactor
Sep 29, 2018
Merged

Remove css-loader and style-loader from the postcss block#293
andywer merged 3 commits intoandywer:release-2.0from
marcofugaro:postcss-refactor

Conversation

@marcofugaro
Copy link
Contributor

Hey, this solves an issue I had with the postcss block, but it changes the way the block is used. So feel free to start a discussion, or tell me if you find a better solution to my problem.

Basically I wanted to use postcss in the production build with the mini-css-extract-plugin. To do this I need to disable the style-loader. I can do that easily in the css block using styleLoader: false. But I couldn't find a way to do it with the postcss block.

It seemed to me a cleaner solution would be to remove the style-loader and css-loader rather than adding a styleLoader option to the postcss plugin.

Let me know if you have anything against this or if I'm missing the reason the style-loader and css-loader were there in the first place.

Copy link
Owner

@andywer andywer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me 👍
Thanks, @marcofugaro!

Does anyone else wanna review before merging?

Copy link
Collaborator

@vlad-zhukov vlad-zhukov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! A long awaited feature for me by the way!

@jvanbruegge
Copy link
Contributor

I thought it was that way all along 😅

@marcofugaro
Copy link
Contributor Author

Glad you guys like it! Do you think we should treat this way also the sass block?

@andywer
Copy link
Owner

andywer commented Aug 30, 2018

@marcofugaro Excellent point! We probably should to keep it consistent, principle of least surprises.

@marcofugaro
Copy link
Contributor Author

marcofugaro commented Aug 30, 2018

@andywer the sass loader is different, the files have a different extension. This next basic example will not work

module.exports = createConfig([
  css(),
  sass(/* node-sass options */)
])

You have to use sass and the css block inside a match block, otherwise they will target different files.

What do you think? Wanted to check with you. Should the basic sass block usage become

const { createConfig } = require('@webpack-blocks/webpack')
const { css } = require('@webpack-blocks/assets')
const sass = require('@webpack-blocks/sass')
 
module.exports = createConfig([
  match('*.{sass,scss}' [
    css(),
    sass(/* node-sass options */)
  ])
])```

@andywer
Copy link
Owner

andywer commented Aug 30, 2018

We could make sass() print a warning if not used within a match() block (just check context.match).

@andreychev
Copy link

That's awesome!

@andywer
Copy link
Owner

andywer commented Sep 18, 2018

Ahh, we haven‘t merged this PR yet... Any objections why not to apply similar changes to the SASS loader (see comments above)?

@vlad-zhukov
Copy link
Collaborator

@andywer, no objections from me 👍

On a sidenote I've got a feeling the match way of using loader blocks should become the only way eventually.

@andywer
Copy link
Owner

andywer commented Sep 18, 2018

I've got a feeling the match way of using loader blocks should become the only way eventually.

100% agreed! 👍
„Explicit is better than implicit“, they said 🤓

@andywer andywer merged commit dba9703 into andywer:release-2.0 Sep 29, 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

Successfully merging this pull request may close these issues.

5 participants