Skip to content

Expressive Code configuration from Starlight leaks into other content collections #3220

Open
@faiz9068

Description

@faiz9068

What version of starlight are you using?

"^0.34.3"

What version of astro are you using?

"^5.8.0"

What package manager are you using?

npm

What operating system are you using?

windows

What browser are you using?

chrome

Describe the Bug

When using Astro Starlight for a docs content collection alongside other content collections, the Expressive Code configuration from Starlight unexpectedly overrides Astro's default Shiki syntax highlighter in other content collections.

Expected Behavior

  • Starlight's Expressive Code configuration should be isolated to the content collection where Starlight is configured
  • Other content collections should continue using Astro's default Shiki syntax highlighter (with github-dark theme and inline styles)
  • Each content collection should maintain its own syntax highlighting behavior independently

Actual Behavior

  • Expressive Code configuration from Starlight is leaking into other content collections
  • The default Shiki syntax highlighter that should be working for the guide content collection is being overridden by Expressive Code
  • All content collections end up using Expressive Code instead of Astro's default Shiki configuration
  • Code blocks in non-Starlight collections render with Expressive Code features (copy buttons, line numbers, etc.) instead of simple inline-styled Shiki output

Reproduction Steps

  1. Create an Astro project with multiple content collections:

    src/content/
    ├── docs/     # Will use Starlight with Expressive Code
    └── guide/    # Should use Astro's default Shiki highlighter
    
  2. Set up basic Astro configuration (no manual syntax highlighter configuration needed):

    // astro.config.mjs
    import { defineConfig } from 'astro/config';
    
    export default defineConfig({
      // Using Astro's default markdown configuration
      // which includes Shiki with github-dark theme
    });
  3. Add Starlight for the docs collection:

    // astro.config.mjs
    import { defineConfig } from 'astro/config';
    import starlight from '@astrojs/starlight';
    
    export default defineConfig({
      integrations: [
        starlight({
          title: 'My Documentation',
          expressiveCode: {
            themes: ['github-dark'], // or custom theme
            defaultProps: {
              wrap: true,
            },
          },
          // other starlight config...
        })
      ]
      // Note: No markdown configuration specified
      // Expecting Astro's default Shiki to work for other collections
    });
  4. Create content with code blocks in both collections

  5. Build and observe that code blocks in the guide collection are rendered using Expressive Code instead of Astro's default Shiki (with inline styles and github-dark theme)

Additional Context

  • This issue breaks Astro's default markdown behavior where Shiki is used with the github-dark theme and inline styles
  • The issue makes it impossible to use Astro's default syntax highlighting for some content collections while using Starlight for others
  • The leak appears to be at the global configuration level, where Expressive Code overrides Astro's entire markdown processing pipeline
  • Expected behavior: content collections not using Starlight should continue to use Astro's default Shiki configuration
  • Even when Starlight is configured with specific Expressive Code settings (custom themes, wrap settings, etc.), these should not affect other content collections
  • A workaround would be highly appreciated while this issue is being addressed

Current Configuration Example

In my project, I have Starlight configured with custom Expressive Code settings, but I expect my guide collection to still use Astro's default Shiki:

// Only docs collection should use Expressive Code
starlight({
  expressiveCode: {
    themes: [DEFAULT_THEME],
    defaultProps: { wrap: true },
  },
  // ...
})
// Guide collection should still use Astro's default Shiki

Possible Solution

Consider scoping Expressive Code configuration to only apply to content collections that are explicitly configured to use Starlight, rather than applying it globally. This would preserve Astro's default Shiki behavior for all other content collections that don't use Starlight.

Link to Minimal Reproducible Example

cdd

Participation

  • I am willing to submit a pull request for this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions