Skip to content
This repository has been archived by the owner on Mar 14, 2024. It is now read-only.

Error when resolving environmentModulePath #11

Open
ryuran opened this issue Aug 27, 2019 · 3 comments
Open

Error when resolving environmentModulePath #11

ryuran opened this issue Aug 27, 2019 · 3 comments

Comments

@ryuran
Copy link
Contributor

ryuran commented Aug 27, 2019

In this test project : https://github.com/ryuran/twing-loader-test

Twing loader fail to resolve environmentModulePath and do not find twingEnv.js.

Child html-webpack-plugin for "index.html":
     1 asset
    Entrypoint undefined = index.html
    [./node_modules/html-webpack-plugin/lib/loader.js!./src/fake.txt] 1.28 KiB {0} [built] [failed] [1 error]

    ERROR in ./src/fake.txt (./node_modules/html-webpack-plugin/lib/loader.js!./src/fake.txt)
    Module build failed (from ./node_modules/twing-loader/dist/index.js):
    Error: Cannot find module 'twingEnv.js'
    Require stack:
    - /Users/yliechti/Sites/twing-loader-test/node_modules/twing-loader/dist/index.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/loader-runner/lib/loadLoader.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/loader-runner/lib/LoaderRunner.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/webpack/lib/NormalModule.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/webpack/lib/NormalModuleFactory.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/webpack/lib/Compiler.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/webpack/lib/webpack.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/webpack-cli/bin/utils/convert-argv.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/webpack-cli/bin/cli.js
    - /Users/yliechti/Sites/twing-loader-test/node_modules/webpack/bin/webpack.js
        at Function.Module._resolveFilename (internal/modules/cjs/loader.js:623:15)
        at Function.resolve (/Users/yliechti/Sites/twing-loader-test/node_modules/v8-compile-cache/v8-compile-cache.js:166:23)
        at Object.default_1 (/Users/yliechti/Sites/twing-loader-test/node_modules/twing-loader/dist/index.js:37:34)
@ericmorand
Copy link
Member

ericmorand commented Aug 27, 2019

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
Copy link
Contributor Author

ryuran commented Aug 27, 2019

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

@ryuran ryuran closed this as completed Aug 27, 2019
@ryuran ryuran reopened this Aug 27, 2019
@ericmorand
Copy link
Member

ericmorand commented Aug 27, 2019

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:

`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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants