Closed mockdeep closed 8 years ago
We have our matcher configured as:
suite.matcher = 'spec/javascripts/**/*_spec.{js,js.jsx}'
@mockdeep thanks for reporting this bug. I'll try to spend some turkey time looking into it. Do you know if it's specific to .jxs
extensions?
@mikepack Sorry, we only use .js
and .jsx
in our javascripts folder, so not sure if other extensions are a problem. We are using haml
in our fixtures, and those seem to be fine.
The reason this is happening is because Teaspoon calls #logical_path
on a sprockets asset in order to get a file URL that can be requested from the browser. We assume this returns a .js
extension every time (like it does in Sprockets 2.x), but this is not the case with .js.jsx
extensions in Sprockets 3.x, in which case it returns .jsx
.
This seems like it could be one of two things:
#logical_path
but I'm not currently aware of another way to determine the URL for a sprockets asset.react-rails
asset pipeline integration and they need specify a .js
extension for #logical_path
.@mikepack how are other extensions like .coffee
handled?
It's mostly handled by sprockets. Sorry, I didn't provide a good resolution for the interim. If you're on Teaspoon 1.1.x, try setting this configuration:
config.suite do |suite|
suite.js_extensions = [/(\.js)?.coffee/, /(\.js)?.es6/, ".es6.js", ".js.jsx"]
end
Thanks! At first blush it looks like that fixed it for me.
:+1:
We just upgraded to Sprockets 3.0 and everything in our app seems to be working alright, but tests with the extension
.js.jsx
no longer work from the command line. Booting into the browser they run fine, but from CLI we just get the cryptic "Syntax error: parse error" from phantomjs and:Not sure if this is a teaspoon issue, but figured I'd start here. We're using
react-rails
which adds.js.jsx
extensions to the asset pipeline.