Closure-compiler: Add an Option To Prevent Rewriting Import/Require Statements for Specific Modules

[ChadKillingsworth]

When working with module systems, there needs to be some way to designate that certain import statements are intended to be runtime imports rather than compile time. This will only apply to CommonJS modules currently until such a time as the compiler recognizes and rewrites the WhatWG Loader Import Statements. See

• https://groups.google.com/forum/#!searchin/closure-compiler-discuss/externalRequire/closure-compiler-discuss/4SpP-o7HKBk/h6NYu1eMIcMJ
• https://gist.github.com/Kegsay/2cb999a78dbd2b8bda95
• #1380

The consensus around this discussion seems to be that this should be a flag, rather than an annotation.

The flag should meet the following criteria:

• The same flag should work for ES6 and CommonJS modules
• It MUST take into account all of the following cases:
  
  
  
  • The --module flags are used and thus both the import and export statements are provided to the compiler as input but divided into separate outputs for runtime loading
  
  
  • The export statement is not provided to the compiler and is therefore external code. This covers core NodeJS module imports.
  
  

[supersteves]

From your linked gist:

/** @externalRequire */
var crypto = require("crypto");

I like this pattern. Presumably this would be quite easy for any contributor to implement so is only blocked by consensus?

[supersteves]

Don't follow your 2nd bullet.

Also if combined with "node_modules" support, is it (theoretically, at least) possible that such external (runtime) modules could have their externs auto generated if the sources were available?

[ChadKillingsworth]

From your linked gist:

/** @externalRequire */
var crypto = require("crypto");

I like this pattern. Presumably this would be quite easy for any contributor to implement so is only blocked by consensus?

No. There already is consensus - it should be a flag and should not be an annotation.

Don't follow your 2nd bullet.

This situation should be covered:

 // http is a core node module
 // The source code will not be provided to the compiler.
 // Type information will be obtained via externs - though that is not part of this issue.
var http = require('http');

Also if combined with "node_modules" support, is it (theoretically, at least) possible that such external (runtime) modules could have their externs auto generated if the sources were available?

Theoretically - yes. In practice - no. Auto generating externs usually produces very poor results. This shouldn't be part of this issue.

[supersteves]

Consensus on a flag - presumably that consensus already agrees on how the flag should identify which requires are external - by a list of wildcard patterns perhaps?

(I didn't mean auto-generated externs, I meant: if Closure could read the sources, it could understand them without actually compiling them?)

[supersteves]

Understood re http example.

[ChadKillingsworth]

Consensus on a flag - presumably that consensus already agrees on how the flag should identify which requires are external - by a list of wildcard patterns perhaps?

No hadn't gotten to that level of detail. A wildcard is an interesting idea I hadn't considered. There's no reason you couldn't do that. Just make sure that the glob syntax matches existing --js flag globs.

[codebreach]

Is this anywhere on the radar? I can help out depending on how much effort you estimate this to be.

[ChadKillingsworth]

Yes - I plan on working on module issues this summer. Most are not small changes though.

[codebreach]

Cool this is blocking us from enabling closure for a pretty large nodejs
codebase, so let us know if we can help test or anything.

On Thu, Jun 16, 2016 at 3:52 AM Chad Killingsworth [email protected]
wrote:

Yes - I plan on working on module issues this summer. Most are not small
changes though.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/closure-compiler/issues/1382#issuecomment-226337705,
or mute the thread
https://github.com/notifications/unsubscribe/AAenDF-b1EDVA1cLCu7OoqW0GLPf4NHgks5qMHspgaJpZM4HB32p
.

[brad4d]

@ChadKillingsworth
Would it make sense to use a single flag to provide both a module name and an optional file path pointing at an externs definition file? (Once we have a way to create such a thing, of course.)

...
--external_module=http=externs/modules/node/http.js \\
--external_module=/some-library/something=externs/modules/some-library/something.js \\
--external_module=someUndefinedThing \\
...