Comments in local SVG files are removed regardless of configuration

[sandrofigo]

What version of astro-icon are you using?

v1.0.1

Astro Info

Astro                    v4.0.8
Node                     v18.18.0
System                   Linux (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             astro-icon

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

When using a local SVG file (containing comments <!-- -->) from the icons folder, the rendered HTML does not contain the comments, although the SVGO plugin removeComments is disabled in the config file:

// astro.config.mjs
import { defineConfig } from 'astro/config';

import icon from 'astro-icon';

// https://astro.build/config
export default defineConfig({
  integrations: [
    icon({
      svgoOptions: {
        multipass: true,
        plugins: [
          {
            name: 'preset-default',
            params: {
              overrides: {
                // customize default plugin options
                inlineStyles: {
                  onlyMatchedOnce: false,
                },

                // or disable plugins
                removeDoctype: false,

                // FOR BUG REPORT:
                removeComments: false,
              },
            },
          },
        ],
      },
    }),
  ],
});

What's the expected result?

Comments should be preserved in the final output, since some icons (e.g. Font Awesome) require the CC BY 4.0 license notice (https://fontawesome.com/license/free)

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-aqxtyy?file=astro.config.mjs

[natemoo-re]

I dug into this a little bit, and it looks like we are passing the svgoOptions through. It seems like Iconify's importDirectory utility has already stripped the comments before we even have access to them.

https://github.com/natemoo-re/astro-icon/blob/38a3a90fe008b5f691a7c06f067367b1c7080261/packages/core/src/loaders/loadLocalCollection.ts#L16-L19

It's possible that refactoring this logic to use our own loading mechanism would solve this issue.