nicks / closure-compiler-old Goto Github PK

Node allows the first line of scripts to start with #! eg:

#!/usr/bin/env node console.log('hello world');

but this gets an error from closure-npc.

Suppose hello.js contains:

/** @constructor */ exports.Hello = function () { };

Then if I reference it like this:

var Hello = require('./hello').Hello; /** @param {Hello} h */ function foo(h) { }

everything works.

However, if I change hello.js to use a separate assignment to export the type.

/** @constructor */ function Hello () { }; exports.Hello = Hello;

I then get an error when I reference the type in @param. Using

/** @const */ exports.Hello = Hello;

works around this.

There's a similar problem on the referencing side, but @const doesn't help there. Specifically, this gets an Unknown type error in the @param annotation.

/** @const */ var hello = require('./hello'); /** @const */ var Hello = hello.Hello; /** @param {Hello} h */ function foo(h) { }

My project does this all the time.

With closure-npc, doing:

var ucd = require('./ucd');

where ucd is a directory, containing a package.json like this:

{ "main": "ucd" }

and a file ucd.js like this:

module.exports = function () { return 10; };

gets an internal compiler error:

java.lang.RuntimeException: INTERNAL COMPILER ERROR. Please report this problem. null Node(CALL): /Users/jjc/closure-test/dir.js:1:10 [source unknown] Parent(NAME ucd): /Users/jjc/closure-test/dir.js:1:4 [source unknown] at com.google.javascript.jscomp.NpmCommandLineRunner$NodeJSModuleLoader.getCanonicalPath(NpmCommandLineRunner.java:548) at com.google.javascript.jscomp.NpmCommandLineRunner$NodeJSModuleLoader.locate(NpmCommandLineRunner.java:450) at com.google.javascript.jscomp.ProcessCommonJSModules$ProcessCommonJsModulesCallback.visitRequireCall(ProcessCommonJSModules.java:158) at com.google.javascript.jscomp.ProcessCommonJSModules$ProcessCommonJsModulesCallback.visit(ProcessCommonJSModules.java:131) at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:563) at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:557) at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:557) at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:557) at com.google.javascript.jscomp.NodeTraversal.traverse(NodeTraversal.java:287) at com.google.javascript.jscomp.NodeTraversal.traverse(NodeTraversal.java:517) at com.google.javascript.jscomp.ProcessCommonJSModules.process(ProcessCommonJSModules.java:84) at com.google.javascript.jscomp.ProcessCommonJSModules.process(ProcessCommonJSModules.java:77) at com.google.javascript.jscomp.NpmCommandLineRunner$NodeJSModuleLoader.load(NpmCommandLineRunner.java:526) at com.google.javascript.jscomp.NpmCommandLineRunner.doRun(NpmCommandLineRunner.java:238) at com.google.javascript.jscomp.AbstractCommandLineRunner.run(AbstractCommandLineRunner.java:374) at com.google.javascript.jscomp.NpmCommandLineRunner.main(NpmCommandLineRunner.java:404) Caused by: java.lang.NullPointerException

In node.js, ArrayBuffer, Uint8Array etc are available, but closure-npc doesn't include the externs for these.

I see the needed definitions in html5.js, along with a lot of other stuff that isn't applicable to node.js.

I have found that a large percentage of the type names that I want to use in a module refer to types that are defined in modules that there is no need to require(). For example, I might have a module that defines a Foo class, and another module that provides functions that operate on the Foo class; the second module often does not need to require() the first module, but it does need to refer to the Foo type in type annotations.

I don't want to add require's to handle this, because it perverts the real dependency structure. I want to describe types purely through annotations.

The WebStorm IDE (from the same folks as IntelliJ) support closure type annotations with node.js. (Potentially this is a big audience for closure-npc.) They appear to put all type names in a single namespace. For example, in the example above, the second module can use Foo in annotations and it just works. This is very convenient, and it would be extremely useful if this could be supported, but perhaps only as an option.

However, I think it would also be useful to provide a syntax to reference a type from a particular module. Maybe "../foo/bar".X. (I think you need literals in the syntax, because module paths can contain arbitrary characters.)