Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Crossorigin attribue for stylesheets #528

Open
zangab opened this issue Jan 22, 2025 · 0 comments
Open

Crossorigin attribue for stylesheets #528

zangab opened this issue Jan 22, 2025 · 0 comments
Labels
bug: pending triage Something doesn't seem to be working, but hasn't been verified

Comments

@zangab
Copy link

zangab commented Jan 22, 2025 •
edited
Loading

Description 📖

Similar issue as #189

Our problem is related to this github issue.
Everything worked fine until we recently updated vite & vite-ruby. We host our assets on S3, however we do have CORS issues on Chrome/Chromium. The reason is a change in Vite and this package, vite-ruby.

The result is a stylesheet beeing loaded twice, one time with the crossorigin attribute (due to async component, f.e.) and one time without (component is pre-bundled).

Example:

  • component B is a sub-component of A that is directly bundled
  • component B is also a sub-component of C that is defined as an async component (we use Vue)

The stylesheet of component B is then inserted by vite-ruby in the <head> via:

<!-- Vite preload -->
<link rel="stylesheet" crossorigin src="cdn.blabla.test/component-b-css-123123.css">

<!-- Vite rails stylesheet via vite_javascript_tag (not preloaded) -->
<link rel="stylesheet" src="cdn.blabla.test/component-b-css-123123.css">

The CORS policy of chrome then blocks the second request because the origin header is missing. Imho an easy fix would be that we could add the crossorigin attribute to the stylesheets as well within the tag helpers. Unfortunately, this is currently not possible within vite-ruby.

Vite however adds the crossorigin attribtue to stylesheets by default therefore the implementations diverge.

  def vite_javascript_tag(*names,
    type: "module",
    asset_type: :javascript,
    skip_preload_tags: false,
    skip_style_tags: false,
    crossorigin: "anonymous",
    media: "screen",
    **options)
    entries = vite_manifest.resolve_entries(*names, type: asset_type)
    tags = javascript_include_tag(*entries.fetch(:scripts), crossorigin: crossorigin, type: type, extname: false, **options)
    tags << vite_preload_tag(*entries.fetch(:imports), crossorigin: crossorigin, **options) unless skip_preload_tags

    options[:extname] = false if Rails::VERSION::MAJOR >= 7

    # here we would need to also pass the crossorigin param
    # see https://github.com/ElMassimo/vite_ruby/blob/main/vite_rails/lib/vite_rails/tag_helpers.rb#L52
    tags << stylesheet_link_tag(*entries.fetch(:stylesheets), media: media, **options) unless skip_style_tags

    tags
  end

Best would be to use a flag if the crossorigin attribute should be applied to the stylesheet tags or not. This would prevent a change to the current behavior.

Reproduction 🐞

Vite Ruby Info

Run bin/rake vite:info and provide the output:

Running via Spring preloader in process 125
bin/vite present?: true
vite_ruby: 3.9.1
vite_rails: 3.0.19
rails: 7.1.5.1
ruby: ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [x86_64-linux]
node: v20.17.0
yarn: 1.22.22

installed packages:
[email protected] /usr/src/app
├─┬ @vitejs/[email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
├── [email protected]
└─┬ [email protected]
  ├─┬ [email protected]
  │ └── [email protected]
  └── [email protected]

Screenshots 📷

Image
Image
@zangab zangab added the bug: pending triage Something doesn't seem to be working, but hasn't been verified label Jan 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug: pending triage Something doesn't seem to be working, but hasn't been verified
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@zangab