I was reading this old issue: https://github.com/rails/rails/issues/1125
The only proposed workaround in that thread is to globally enable bare mode always.
I use oojspec (a gem based on rails-sandbox-assets gem that will allow me to reuse my assets with sprockets requires support) to test my client-side code.
Sometimes it would be useful if I could test private functions in my assets.
An option would be to export them using some kind of convention, like prefixing private functions with underscore in some namespace so that I could access them from tests, but I'd prefer to do something like this instead in some cases:
http://philipwalton.com/articles/how-to-unit-test-private-functions-in-javascript/
The idea is to include the private function in the same scope as your test suite so that you're able to call them, only in that test context.
Also, while doing that, I'm not interested in private functions defined in other files than the one I'm interested in for the test suite purpose. So, a global bare approach is not only undesirable but could also lead to conflicts, which is dangerous.
Here's an example for creating a pagination bar:
pagination.js.coffee
#= require views/pagination-links
@buildPaginationLinks = (currentPage, lastPage) ->
pages = createSelectablePages currentPage, lastPage
JST['views/pagination-links'](currentPage, pages)
createSelectablePages = (currentPage, lastPage) ->
# code I want to test separately
So, an ugly option currently would be adding something like this to the end of this file for testing purposes:
@buildPaginationLinks.createSelectablePages = createSelectablePages
Or exporting it to any other place where I would be able to access it production environment. Not really a big deal, but I would be much happier if I could simply call "createSelectablePages" from my test suite and only from there. Maybe something like:
pagination_spec.js.coffee
#= require pagination, bare: true
describe "pagination", ->
@example "createSelectablePages", ->
@expect(createSelectablePages(2, 30)).toEq [1, 2, 3, 4, 5, 6, 30] # an ellipsis ("...") would be included between 6 and 30.
# other test cases
Another option I'm considering is adding something like "#= require spec_helper" in the first line (actually I already have this in my specs), and adding something like "@testingScope = {}" to it (actually I use the "g" as a global namespace instead of the window, so it would read like "g.testingScope = {}" in my specific application). This way, I'd be able to do something like "@testingScope.paginationCreateSelectablePages = createSelectablePages if @testingScope?". This is better but if I could convince you to reconsider adding support for defining the bare mode per file I'd be much happier.
In that old issue, it was asked what should happen in case two assets require the same file, one of them asking for bare while the other not. I believe raising an error would be fine in such situation, as it should work like embedding the required asset inside that one scope (function).
Maybe another option would be to create a new helper to aid with such cases. Instead of "require" we could call "embed" instead. Then there's no need to handle the above mentioned problem as the solution would be simple. "embed" will always embed the content (pre-compilation concatenation step, similar to C pre-compile directives/macros). If you do it more than once you'll have the code duplicated in different scopes/functions, but then it's the developer's choice and not a bug.
Would it be possible for you to reconsider this feature request with the testing use case in mind?
Thanks in advance,
Rodrigo.
