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

Template and JS file naming conflicts #91

Open
disbelief opened this issue Jan 8, 2014 · 6 comments
Open

Template and JS file naming conflicts #91

disbelief opened this issue Jan 8, 2014 · 6 comments

Comments

@disbelief
Copy link
Contributor

Hi there,

I've recently encountered a naming conflict with handlebars_assets and other regular javascript files in my asset pipeline. My directory structure looks like this:

app/assets/
  javascripts/
    application1/
      views/
         some_view.js
  templates/
    application1/
      views/
        some_view.hbs

When compiled, this attempts to create two files named some_view.js in public/assets/ — one for the js view file, and one for the hbs template.

An obvious workaround is to add a prefix otherwise change/remove one of the parent directories of some_view.hbs, but even then collisions could occur.

So I'm wondering if it might be possible to specify a custom extension for the compiled handlebars templates? For example, an extension of .hbs.js for the output would allow both files to exist in public/assets without any conflicts.

Is there a way of doing this with handlebars_assets currently?

@AlexRiedler
Copy link
Collaborator

I was trying to figure out a good way of doing this; considering that the I assume your adding "templates" directory to your asset pipeline. The gem does not actually choose the name of the output file (but the Sprockets pipeline does).

You could change the path_prefix on the config so they do not map to the same file though (although I assume this does not meet your needs) -- so that it would be templates/application1/views/<>.js

If I think of anything I will comment about it later.

@disbelief
Copy link
Contributor Author

Thanks for the reply @AlexRiedler

Actually as I understand it the "templates" directory is added to the asset pipeline automatically by handlebars_assets, and that is what the HandlebarsAssets::Config.path_prefix option is for. It just tells handlebars_assets which directory contains the .hbs files to be compiled. So it's specifying the input directory, not the output directory.

I'm wondering if there might be an option that can be passed through to Sprockets to force a different file extension for the outputted files?

@AlexRiedler
Copy link
Collaborator

it does not actually add the directory given to the asset pipeline; it takes that as the part of the path it should remove from the template name, for injection into JST (or whatever javascript namespace you are using).

@AlexRiedler
Copy link
Collaborator

It looks like any two files on the asset path must have unique file names (upto path of the asset paths - excluding file extensions). It will grab whichever is listed first otherwise. If you do find a solution though (or work-around) that would be interesting.

@disbelief
Copy link
Contributor Author

Ah I see thanks for the clarification. I'm a bit new to this codebase, just looking at it for the first time today.

So I got a little bit further by monkey patching TiltHandlebars in my rails app:

# initializers/hbs_monkeypatch.rb
module HandlebarsAssets
  class TiltHandlebars
    def self.default_mime_type
      'application/x-javascript-hbs'
    end
  end
end

# initializers/mime_types.rb
hbs_js_type =  MIME::Type.new('application/x-javascript-hbs') do | type | 
  type.extensions = %w( hbs.js )
  type.encoding = '8bit'
end
MIME::Types.add hbs_js_type
Sprockets.register_mime_type('application/x-javascript-hbs', '.hbs.js')

Now Sprockets is compiling the files using the x-javascript-hbs mime type, but the compiled files are being saved without any extension at all (public/assets/view instead of public/assets/view.hbs.js)

I thought that Sprockets.register_mime_type call might have done it, but it doesn't seem to have had any effect.

This is all seeming like kind of a bad idea now that I look at it 😦

@AlexRiedler
Copy link
Collaborator

I remember something weird about extensions and mime type relations...; something with rails during bootup changing something so that it does not work in initializers only in initialization:after of the application. I however am busy most the day today; maybe later tonight or tomorrow I can determine where the extension comes from more concretely. Thanks for the idea, maybe there is something along those paths.

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