Is it actually useful for {{helper}} to always be relative to the current directory?

[dschissler]

I don't see how having view helpers specific to the current directory is realistically helpful in a project. Generally these helper functions are defined globally for all templates with a registerHelper function.

So why not have the default behavior to load from the helperDirs set from the webpack.config loader object instead of needing to prepend $?

My main issue is that $ is interfering with handlebars-xgettext (translation extractor) being able to recognize the function as a message function. I want to be able to use this in a way where my templates would look the same as if I were not using this and it doesn't appear to be possible.

Perhaps there could be a searchHelperDirsByDefault configuration option.

[diurnalist]

Since webpack/loader-utils#2, it should be possible to use rootRelative = ~ to accomplish this behavior, I think. Can you try?

In my opinion, it kind of makes sense for this to be the default, instead of ./. Maybe in a major version bump down the road...

[dschissler]

I've given up on using this for now. Every time that I try it ends up being a huge unsuccessful time sync for me.

[stevewillard]

Agree with this. I just want to put helpers into a folder, and have them globally available in all templates. Making them relative is really bizarre.

[altano]

Sorry, it's been a while but didn't I show how this is done in the example?: https://github.com/altano/handlebars-loader/blob/master/example/webpack.config.js

Can you see if using the resolve fallback option makes this possible for you, @stevewillard

[stevewillard]

Hmm that doesn't seem to help.

module.exports = {
    watch: true,
    entry: {
        main: "./js/main"
    },
    resolve: {
        fallback: path.join(__dirname, "helpers")
    },
    module: {
        loaders: [
            { test: /\.template$/, loader: "handlebars-loader?extensions=template" }
        ]
    }
};

ERROR in ./templates/application/item.template
Module build failed: Error: You specified knownHelpersOnly, but used the unknown helper bucketPrefix - 4:20
    at new Error (<anonymous>)

And I have a /helpers/bucketPrefix.js

module.exports = function(url, path) {
    return window.CDN_BUCKET + url + ((typeof path === "string") ? path : "");
};

It works if I do $bucketPrefix -- I would really prefer to not do this, because I'm trying to convert a large project to webpack from RequireJS

[altano]

Oh right, now I remember, that's why we added the helperDirs option. I should add an example that shows how to use that since I haven't actually tried it myself. Can you give that a whirl?

[altano]

Disregard last message, that's what this thread is about. I'll spend some time today catching up but bare with me because I've forgotten all of these discussions :)

[altano]

This works as is. "$" causes the item to be loaded as a module (which can make use of webpack resolve options), but you don't have to use it. If you use the helperDirs option, you can use helpers without "$" prefix.

If your helper is in a nested subdirectory, there is one caveat: you cannot use forward slashes in Handlebars identifiers, which includes helper names, without escaping them with brackets. You can see in this JSFiddle that it is required with just Handlebars.

So the solution is to just put your helper name, when it has nested folders, in angle brackets.

I created this example to illustrate how to do it.

Please let me know if you can't figure it out.