Inject is requesting resources when the require is in a false condition

[patrickliechty]

We have services that work on the server side with Node.js and on the client side. We request the dependencies with require differently on both sides. Inject will execute the require command even if the condition is false. This causes a 403 forbidden error. It would be nice if it did not fetch the resource unless the condition was true.

if(condition) {
require("utilservice");
}

[jakobo]

Thanks for the feedback and the bug report. Part of the problem is inherent in Inject's design. Since we do static analysis of the files, we are not really able to handle conditional require statements. In the above example, this is especially important since require() is a synchronous call. With no callbacks around it, the module must be made available before the require() statement is encountered. NodeJS gets around this by having all calls to their require() be synchronous.

I do have some solutions that would be possible using Inject's features however.

Pragmas: There's a discussion in #292 about adding some kind of pragma syntax that would disable scanning for blocks of code. If it's known the code is being used browser side and that condition will always evaluate to false, we could use these pragmas to tell Inject to ignore those synchronous require statements.

Inline AMD definitions: If the conditions are externally visible, the needed modules could be shimmed using a define statement. The code (one line for brevity) might look like if (condition) { define('utilservice', [], {}); } However, this would only work if the condition could be tested at a higher level.

Content Modification Rules: Similar to some of the talk in #292, there may be some kind of rules that would make it possible to modify the source code at the time we are scanning for dependencies. This is easier if the condition is something like if (window && window.document) and significantly harder if the condition was to be something like if (localVariable === true).

Thanks again for trying out Inject, and let me know if any of these three ideas might be a good route for us to explore.

[patrickliechty]

I followed what you say and it is a good work around, thanks.