Argon.js fails with Webpack

[ammulder]

I gather this is usually caused by calling require with a variable instead of a string:

WARNING in ./~/@argonjs/argon/dist/argon.js
1:3743-3750 Critical dependency: require function is used in a way in
which dependencies cannot be statically extracted

WARNING in ./~/@argonjs/argon/dist/argon.js
1:3789-3796 Critical dependency: require function is used in a way in
which dependencies cannot be statically extracted

[speigg]

Hi, thanks for reporting this issue! I believe this is fixed in the develop branch. Can you try installing @argonjs/argon@next ?

[ammulder]

I tried installing @next as you suggest (it gave me version "^1.2.0-1") and I still get the problem.

On further inspection, it seems to be caused by this (in the first line of dist/argon.js):

D="undefined"!=typeof System&&System._nodeRequire||"undefined"!=typeof require&&require.resolve&&"undefined"!=typeof process&&require

And if I just change that to D=true then it's happy. I'm not sure where that logic is coming from to attempt to inspect the runtime environment for a require function, but to be clear, it appears to be something in the argon build.

[speigg]

@ammulder Any chance you have tried webpack@2 ?

[speigg]

The checks for a require function are intentional, as argon.js is a built as a UMD library, which means it can be loaded via commonjs, AMD, or ES6 module loaders. I believe the problem you are running into is due to bug in webpack@1, which was fixed in webpack@2 (see webpack/webpack#2675).

[ammulder]

According to node_modules/webpack/package.json I'm already on Webpack 2.2.0

I don't think Webpack has solved the general issue, which appears to be that whenever it sees "require" it tries to analyze what you're "requiring" so it can handle that. But in the argon.js usage that's causing the problem, you're only checking whether the require function exists, not actually "requiring" anything. I guess Webpack doesn't figure that out?

[speigg]

So good news / bad news: I found that the latest version of jspm@next fixes this issue in creating a build that Webpack can understand, but unfortunately I can't update jspm yet because I'm held back by another bug in a package that needs to be updated with jspm@next. Technically, however, this issue seems to be a problem in Webpack. Perhaps you can open an issue with them?

[speigg]

Waiting on frankwallis/plugin-typescript#204 to be resolved then I can "fix" this