How do I disable postcss-import in Bud?

bud
1

I am trying to switch from Mix to Bud and I (or rather the frontend dev on the project) want to use the native @import for CSS instead of having @import result in the build process merging the files.

For example

File app.css

@import url(dev-test-partials/dev-test-partial-1.css);

.app {
  background: blue;
}

File dev-test-partials/dev-test-partial-1.css

.partial_1 {
  background: green;
}

renders one file with both rules (.app and .partial_1) in it. I want the resulting file to look exactly like app.css (but minified and all other stuff that Bud does, except merging).

I have tried everything I can find in the Bud documentation but I always end up with one CSS-file with all @imports merged in to the file.

I have tried the following in bud.config.js

app.postcss.unsetPlugin('import')
Based on @roots/bud-postcss | bud.js

app.postcss.unsetPlugin('postcss-import');
The same as above but trying another key. After running yarn bud build now, I get:

BudError
✘ Plugin import does not exist

Which leads me to believe that I am on to something but I am guessing that Bud relies on postcss-import actually being available. So I added:

app.postcss.use(['postcss-nested', 'env']);
Based on https://bud.js.org/extensions/bud-postcss#adding-a-plugin

This leads to yarn bud build completing successfully but with the undesired outcome as described above.

So I removed all the lined mentioned above and tried

bud.postcss.setPostCssOptions({
  plugins: [`postcss-nested`, `postcss-preset-env`],
})

Based on https://bud.js.org/extensions/bud-postcss#overriding-postcss-options-directly

But still no success. Is there a way to achieve what I want?

I am running v6.20.0 of @roots/bud and @roots/sage.

2

I have also tried

app.postcss.setPluginOptions('postcss-import', {
        filter: () => false
    });

Which still does not stop @import from merging files.

If I change “postcss-import” to something like “postcss-importX”, I get an error telling me that “Plugin importX does not exist”, which leads me to believe that I am not that far from the solution.

3

Hey @folbert!

Because css-loader follows postcss-loader, disabling postcss-import will still result in dependency resolution.

You can bypass this by passing an absolute URL or setting import: false on the css-loader, alongside your postcss-import tweak:

  app.postcss.setPluginOptions('postcss-import', {
    filter: () => false
  });

  app.build.items.css.setOptions({
    ...app.build.items.css.getOptions(),
    import: false
  });

But this is really breaking the module bundler approach of Bud and Webpack. I would to look at implementing a filter function which creates an escape hatch into bypassing @import, rather than it being a default.

You’ll also need to handle the ‘orphaned’ CSS assets so they’re processed(?), extracted and emitted in dev and prod builds.

1 Like
4

Thank you for the info @talss89!

Adding your example led to the @import not being touched in the build process :tada:

But all urls() like background-image: url('../images/image.png') became url('webpack:///mini-css-extract-plugin//app/themes/...) .

I fixed this by changing

app.setPublicPath('/app/themes/mesta-maestarna/dist/');

to

app.setPublicPath(app.env.get('WP_HOME') + '/app/themes/[theme-name]/dist/');

I hear what you are saying and if I run into any more issues, I will try to persuade the other dev to change his mind about this :slight_smile:

Regarding having to process the other CSS-files, I have found Bud config for outputting multiple css files (from scss for ACF Blocks) and is hoping to make that process automatic for all css files in a folder named “partials”.

5

So… I have decided this is not a feasible way to build CSS-files and will stop trying to make Bud and PostCSS do things that it is, probably for a good reason, not very keen on doing.

If multiple CSS-files are needed, it is probably easier and better to create multiple entries in Bud and enqueue them as usual.

Somewhat related links about one large vs many small CSS-files.

https://gomakethings.com/modular-css-and-different-ways-to-structure-your-stylesheets/

Let’s just say it depends on so many factors which approach is the best and it is probably better to focus on writing code instead of debating this :slight_smile:

3 Likes