Error when resolving environmentModulePath about twing-loader

[ericmorand]

Thanks for the report.

Currently, the path to the module that resoves to the Twing environment needs to be absolute:

options: {
    environmentModulePath: path.resolve('twingEnv.js'),
    renderContext: {
        foo: 'bar'
    }
}

It makes sense to me because require will consider it as a node_modules package if it comes without a path prefix. For information I also tried with a relative path like ./twingEnv.js and it doesn't work. Again, it makes sense since require will try to resolve it from the directory of the loader script itself.

Anyway, this means that either the documentation is wrong (and then I need to fix it) or the loader should resolve the path itself before requiring it (and then I need to fix it :D ).

I'm not the most appropriate guy to take that kind of design decision about webpack (I barely use it), but my thought is that it should be possible to use a node_modules package as environmentModulePath or have something like module-alias do the resolution job and that twing-loader should not get in the way - i.e. it should not try to resolve environmentModulePath by any mean.

So I'm tempted to consider that the current design decision is the best one and that the documentation needs to be fixed.

What do you think?

[ryuran]

Why use a path and not directly some js ? User could use require for file or node module.

[ericmorand]

That was my first idea. It works perfectly when using "render at compile time" but when the template needs to be rendered at runtime, the environment used to compile it is needed in the bundle. And except if I'm wrong, the only way to have webpack include the environment into the bundle is to require it from its path in the loader output.

This is done here:

twing-loader/src/index.ts

Line 53 in b20bf0e

`const env = getEnvironment(require('${environmentModulePath}'));`

Once again, there may be some better approach and I'm totally open to them. I'm currently looking at how other loaders deal with this - I know for sure that some forks of twig-loader that allows for customization use the same approach but I'm not sure there is no better way.

Edit: handlebars-loader also uses that approach when one want to provide a custom runtime.