[Bug]: PurgeCSS CLI not working with config file

[timjuedemann]

Describe the bug

While I still feel like I am the one doing something wrong here, I feel like I have exhausted all possible error sources on my end:

I am trying to run PurgeCSS via the CLI using the following config file:

// purgecss.config.js

console.log("Using purgecss.config.js");

module.exports = {
    content: ["index.html"],
    css: ["style.css"],
};

The directory structure of my project directory is as follows:

index.html
node_modules/
package-lock.json
package.json
purgecss.config.js
style.css

When I run PurgeCSS with the following command without the config file it works as expected:

purgecss --content index.html --css style.css --output style.purged.css

However, when I try to run it with the config file, I only get the output from the console.log but my CSS isn’t being processed:

purgecss --config ./purgecss.config.js --output style.purged.css

I assume there’s something wrong with my config file but I can’t figure out what exactly.

To Reproduce

1. Run purgecss --content index.html --css style.css --output style.purged.css
2. File style.purged.css is created
3. Delete style.purged.css
4. Run purgecss --config ./purgecss.config.js --output style.purged.css
5. Using purgecss.config.js logged to console but style.purged.css is not being created

purgecss-testing.zip

Expected Behavior

I would expect running PurgeCSS using the config file to give me the same result as running it without, i.e. create a new file style.purged.css in my project directory containing the purged CSS. I need to be able to run PurgeCSS with a config file because I rely on being able to define a custom extractor.

Environment

macOS 15.3
purgecss 7.0.2
node 20.11.1

Add any other context about the problem here

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[timjuedemann]

Update

I downgraded to purgecss version 6.0.0 and now my config file is being processed as expected which leads me to believe that this is indeed a bug?

[anthony0030]

I have the same problem. After updating to version 7, my CSS output is almost empty. I am also using a config file for the content.

[codyseibert]

Same issue for me, the cli command does not seem to generate any output file, not sure if it's doing anything. I downgraded to 6.0.0 and it works fine.

[esausaravia]

Same problem with any simpliest purgecss.config.js

console.log("Using purgecss.config.js");

module.exports = {
    content: ["./src/index.html"],
    css: ['./dist/assets/index-CQ6HI1ts.css'],
};

running

purgecss --config ./purgecss.config.js --output dist/assets

Also, I can confirm v6 is working fine

[andrewburgess]

If it helps with tracking it down, it looks like when

purgecss/packages/purgecss/src/index.ts

Line 93 in b27293f

options = await import(t);

imports the config file, the resulting module is

{
    default: {
        // your configuration
    }
}

The spread operator that happens below doesn't end up applying any of the configuration values because it only adds the default property to the returned options.

You can work around this by making your configuration file an ES Module (change file type from .js to .mjs) then export each configuration option explicitly

For example:

// purgecss.config.mjs
export const content = ["./index.html"];
export const css = ["./style.css"];

[neven-mikleus]

If it helps with tracking it down, it looks like when

purgecss/packages/purgecss/src/index.ts

Line 93 in b27293f

options = await import(t);
imports the config file, the resulting module is
{
default: {
// your configuration
}
}
The spread operator that happens below doesn't end up applying any of the configuration values because it only adds the default property to the returned options.

You can work around this by making your configuration file an ES Module (change file type from .js to .mjs) then export each configuration option explicitly

For example:

// purgecss.config.mjs
export const content = ["./index.html"];
export const css = ["./style.css"];

I can confirm that witj mjs is working fine in V6.

[proog]

It's not just a CLI issue – programmatic usage with a file path (instead of an options object) fails as well. As pointed out by #1327 (comment) the dynamic import is the issue.

It looks like it was broken with 025aa03 because Rollup was upgraded to v4. Rollup used to rewrite dynamic import(...) expressions to require(...), but Rollup v3 changed the defaults to preserve them as-is.

Setting dynamicImportInCjs=false reverts to the old behavior and fixes the issue, but would likely break compatibility with importing ESM configuration files.

Maybe a low-impact way to handle both could be something like

const o = await import(t);
options = o.default ?? o;

or using o[Symbol.toStringTag] === "Module" to check if the import is a module namespace object, which seems to be a common solution.