@wxt-dev/auto-icons generates duplicate icons when custom sizes overlap defaults

[zryyyy]

Describe the bug

@wxt-dev/auto-icons intentionally merges custom icon sizes with its default sizes, but it does not deduplicate the resulting array.

For example, with:

autoIcons: {
  baseIconPath: 'assets/icon.svg',
  sizes: [16, 32, 48, 96, 128],
  developmentIndicator: false,
},

the configured sizes are concatenated with the defaults [128, 48, 32, 16], resulting in an effective array equivalent to:

[16, 32, 48, 96, 128, 128, 48, 32, 16]

The overlapping sizes are then processed twice by Sharp and written to the same output paths twice.

The build summary shows:

.output/chrome-mv3-dev/icons/128.png
.output/chrome-mv3-dev/icons/128.png
.output/chrome-mv3-dev/icons/16.png
.output/chrome-mv3-dev/icons/16.png
.output/chrome-mv3-dev/icons/32.png
.output/chrome-mv3-dev/icons/32.png
.output/chrome-mv3-dev/icons/48.png
.output/chrome-mv3-dev/icons/48.png
.output/chrome-mv3-dev/icons/96.png

I understand that merging custom sizes with the default sizes is intentional. However, duplicate sizes should be removed before generating icons.

For the configuration above, each of 16, 32, 48, 96, and 128 should only be generated once.

A possible fix would be to deduplicate the resolved sizes:

const sizes = [...new Set(parsedOptions.sizes)];

and use sizes in the manifest, icon generation, and public-path hooks.

Reproduction

A minimal reproduction project.tar.gz is attached to this issue.

Steps to reproduce

1. Install the dependencies:

npm install

2. Use the following wxt.config.ts configuration:

import { defineConfig } from 'wxt';

export default defineConfig({
  modules: [
    '@wxt-dev/module-react',
    '@wxt-dev/auto-icons',
  ],
  autoIcons: {
    baseIconPath: 'assets/icon.svg',
    sizes: [16, 32, 48, 96, 128],
    developmentIndicator: false,
  },
});

3. Start the development build:

npm run dev

4. Check the build summary.

The entries for 16.png, 32.png, 48.png, and 128.png are each listed twice, while 96.png is listed once.

Removing the default sizes from the custom array and using only:

sizes: [96]

avoids the duplicate processing because the default sizes are appended automatically.

System Info

npx envinfo --system --browsers --binaries --npmPackages @wxt-dev/auto-icons,wxt,vite

  System:
    OS: Windows 11 10.0.26200
    CPU: (16) x64 AMD Ryzen 7 4800H with Radeon Graphics         
    Memory: 10.61 GB / 31.37 GB
  Binaries:
    Node: 24.18.0 - C:\Users\Matrix\AppData\Local\fnm_multishells\28944_1783789127586\node.EXE
    npm: 11.16.0 - C:\Users\Matrix\AppData\Local\fnm_multishells\28944_1783789127586\npm.CMD
    pnpm: 11.9.0 - C:\Users\Matrix\AppData\Local\pnpm\bin\pnpm.CMD
  Browsers:
    Chrome: 150.0.7871.114
    Edge: Chromium (149.0.4022.98)
  npmPackages:
    @wxt-dev/auto-icons: ^1.1.1 => 1.1.1 
    wxt: ^0.20.27 => 0.20.27

Used Package Manager

npm

Validations

• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[zryyyy]

Additional verification:

I temporarily added the following log after the module options are resolved in the installed @wxt-dev/auto-icons@1.1.1 package:

console.log(parsedOptions.sizes);

With this configuration:

sizes: [16, 32, 48, 96, 128]

the logged value is:

[
  16, 32, 48, 96,
  128, 128, 48, 32,
  16
]

This confirms that the duplicate entries are introduced during option merging, before the manifest and build hooks run.

It also rules out the duplicates being caused by:

• the module being registered twice;
• existing icon files in the public directory;
• the build summary only displaying the same file twice.

Since the build:done hook iterates over parsedOptions.sizes directly, Sharp processes the overlapping sizes twice and writes them to the same output paths twice.

[zryyyy]

One related API-design question may also be worth discussing: should autoIcons.sizes replace the default sizes, or extend them?

The current behavior treats sizes as additional sizes and merges them with the defaults. That is useful when someone only wants to add a size such as 96, but it may be surprising because array-valued configuration options are often interpreted as a complete user override.

For example:

autoIcons: {
  sizes: [96],
}

could reasonably mean either:

// Replace the defaults
[96]

or:

// Extend the defaults
[96, 128, 48, 32, 16]

Both behaviors are defensible, but making the intended semantics explicit would help.

A few possible directions would be:

1. Keep the current additive behavior, deduplicate the merged result, and document that sizes means “additional sizes”.
2. Change sizes to replace the defaults, which may be more intuitive for a configuration field named sizes.
3. Make the distinction explicit with separate options, for example:

sizes: [16, 32, 48, 128],
additionalSizes: [96],

Changing the current merge behavior could be breaking, so deduplication alone is probably the safest immediate fix. I am also happy to open a PR with the preferred approach, including tests and documentation updates, if the maintainers would find that helpful.

[smashedr]

This was the 1st thing I noticed when I started using auto-icons.

My work-around was to only define the extra sizes i needed.

  autoIcons: {
    enabled: true,
    baseIconPath: 'assets/icon.svg',
    developmentIndicator: false, // 'overlay' | false
    sizes: [96, 24], // Dfault: 128, 48, 32, 16
  },

Reference: https://github.com/smashedr/wxt-extension/blob/master/wxt.config.ts#L13

In hindsight I probably should have ignored the duplication, because now I will need to update all my configs once this is completed.

[YashNayakk]

I've got a fix ready for this (dedupe the merged sizes via Set) — opening a PR shortly.

[zryyyy]

Thanks for opening PR!

I’m wondering whether it would be worth changing sizes from extending the defaults to replacing them🤔. Keeping the current behavior avoids a breaking change, but replacement may be closer to what users generally expect from an option named sizes.

I think it’s worth discussing, and I’d be interested to hear what others think.

[smashedr]

I’m wondering whether it would be worth changing sizes from extending the defaults to replacing them🤔. Keeping the current behavior avoids a breaking change, but replacement may be closer to what users generally expect from an option named sizes.

I think it’s worth discussing, and I’d be interested to hear what others think.

I would expect the default behavior to be if I set custom sizes, it would only generate those sizes.
That being said, the default sizes 128, 48, 32, 16 are expected and should not be excluded.
Therefore, the current PR should work in all cases...

[YashNayakk]

Thanks both! This PR is scoped to just the dedup fix (#2491) so it stays
non-breaking. Extend-vs-replace seems worth its own discussion — happy
to help there too if maintainers want to go that direction.