Using sanitize reset in SvelteKit triggers error

[TGlide]

UnoCSS version

0.56.5

Describe the bug

When using UnoCSS with SvelteKit, with the @unocss/svelte-scoped package, if you pass in @unocss/reset/sanitize/sanitize.css into the injectReset option, the following error appears. Switching to @unocss/reset/normalize.css triggers no errors.

Reproduction

I assume no reproduction is needed from my description above. If one is needed, let me know and I'll happily provide one.

System Info

No response

Validations

• Read the Contributing Guidelines.
• 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.

[henrikvilhelmberglund]

:where(nav li)::before {
  content: "\200B";
  float: left;
}

This thing breaks it, I have no idea why but you can delete it in the sanitize.css until it's fixed.

[TGlide]

:where(nav li)::before {
  content: "\200B";
  float: left;
}

This thing breaks it, I have no idea why but you can delete it in the sanitize.css until it's fixed.

Thanks for the workaround!

[henrikvilhelmberglund]

No problem!

It seems hard to fix in the reset package itself though because the files are not in this repo, instead they are brought in from the sanitize repo which seems unmaintained. It would probably have to be replaced in svelte-scoped when reading the .css reset files, replacing "\200B" with "​". aka a real zero width space character.

So... My boring suggestion is to just use another reset file for now. 😊
Perhaps @jacob-8 would like to fix this though since it's a bit confusing.

[jacob-8]

Thanks for solving this @chu121su12!

I'm going to leave it alone for now because I don't understand the \200b very well yet, but I do want to write down my thoughts.

When it comes to those regexes, I would prefer to make them more readable like this:

export function replaceGlobalStylesPlaceholder(code: string, stylesTag: string) {
  // ...
  const escapedStylesTag = escapeBackslashesAndTemplateLiteralCharacters(stylesTag)
  return code.replace(QUOTES_WITH_PLACEHOLDER_RE, `\`${escapedStylesTag}\``)  
}

const BACKSLASH_NOT_FOLLOWED_BY_BACKTICK_OR_DOLLAR_SIGN = /\\(?![`$])/g
const UNESCAPED_BACKTICK_OR_DOLLAR_SIGN = /(?<!\\)([`$])/g

export function escapeBackslashesAndTemplateLiteralCharacters(code: string) {
  return code
    .replaceAll(BACKSLASH_NOT_FOLLOWED_BY_BACKTICK_OR_DOLLAR_SIGN, '\\\\')
    .replaceAll(UNESCAPED_BACKTICK_OR_DOLLAR_SIGN, '\\$1')
} 

I also would prefer just placing a global.test.ts file right beside with something like:

describe(escapeBackslashesAndTemplateLiteralCharacters, () => {
  it('to-fill-in', () => {
    const escapedUnicode = 'li::before { content: "\200B"; }'
    expect(escapeBackslashesAndTemplateLiteralCharacters(escapedUnicode)).toContain('\\200B')
  })
})

This is a small unit test that was placed the more high-level tests of the preprocessor over different use cases. I'm presuming you are using a .css file because Typescript won't actually run with a 'legacy octal escape sequence like \200B. But is that important to test this the root issue here? Is there another character sequence we could test instead?

Let me know if you can help me understand things better, otherwise I'm glad you had a fix for us here!