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.

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

Xray fails to inject itself when using jQuery in Webpacker #106

Open
phoozle opened this issue Feb 27, 2020 · 1 comment
Open

Xray fails to inject itself when using jQuery in Webpacker #106

phoozle opened this issue Feb 27, 2020 · 1 comment

Comments

@phoozle
Copy link

phoozle commented Feb 27, 2020

Not sure if anyone has had this issue before or I have misconfigured something badly but as far as I can tell xray-rails will not work when using jQuery from Webpacker due it scanning your html for a jQuery script tag in your

Gem versions I am using:
Rails: v5.2.3
Sprockets: v3.7.2
Xray: 0.3.2

Offending line:

# middleware.rb
if append_js!(body, 'jquery', 'xray')
  inject_xray_bar!(body)
end

Workaround:
Create an empty jquery.js somewhere so that it is included in your application.js manifest file which allows X-ray to append itself. Make sure that your Webpack bundle that includes jQuery is loaded before your sprockets application.js. E.g.

  <%= javascript_pack_tag 'application' %>
  <%= javascript_include_tag 'application' %>
@TylerRick
Copy link

TylerRick commented Feb 24, 2021

I ran into a similar problem (mine happened to be due to Sprockets 4, but I'm sure I would/will eventually run into it with Webpack too): see #110

I thought of doing that same workaround, too — creating an empty jquery.js — but then fortunately realized that there's an even easier solution — just include xray yourself — instead of including jquery just to get xray to auto-add itself after jquery:

<%= javascript_include_tag 'xray', nonce: true if Rails.env.development? %>

Now that I've thought more about it, I honestly think the auto-adding the script feature is overrated, over-complicated, and error-prone (#98, #100), and I propose we just remove it (#110).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants