clutz + google/protobuf + commonjs #334
Comments
|
Welcome :) Clutz is basically a wrapper around the Closure Compiler and what you are seeing is the Closure Compiler rejecting your code, because of some unknown symbols. It a bit of a wild chase to find where each of those comes from, and passing all those deps to the clutz invocation, but here is a start: COMPILED - https://github.com/google/closure-library/blob/master/closure/goog/base.js#L32 Also I don't recommend using |
|
Thanks for the help! OK, I did a bit of hacking and reading a got a little further. First, I had to patch clutz so it invokes closure with commonjs support: diff --git a/src/main/java/com/google/javascript/clutz/Options.java b/src/main/java/com/google/javascript/clutz/Options.java
index 2cceaca..887a2dc 100644
--- a/src/main/java/com/google/javascript/clutz/Options.java
+++ b/src/main/java/com/google/javascript/clutz/Options.java
@@ -86,6 +86,7 @@ public class Options {
options.setLanguageOut(CompilerOptions.LanguageMode.ECMASCRIPT5);
options.setCheckTypes(true);
options.setInferTypes(true);
+ options.setProcessCommonJSModules(true);
options.setIdeMode(true); // So that we can query types after compilation.
return options;
}I also tweaked my list of externs as you suggested, but now I have a new problem! Any ideas on where to go from here? The lines: are present in |
|
Hm, looks like I am at least partially running into google/closure-compiler#954. |
|
Following the advice on that issue (aliasing |
tamird
changed the title
|
This is really odd, because most likely the first line of That's said, most likely after this change you will discover a slew of other ones, because you need to pass all your dependencies to the clutz execution - that includes jspb's message.js, closure's array.js, etc. In our usage of clutz it is plugged into a build system that keep track of all dependencies. |
In fact, it does not say this! It only says
Are you sure? That's certainly the case when producing closure-style code from |
|
aha, that's the problem then, you need to produce code using closures' dependency mechanism if you are to feed to through clutz. Again clutz is just a wrapper around closure compiler with a .d.ts emit instead of regular .js emit. |
|
Understood, but I thought the closure compiler could also handle commonjs. Perhaps I should take it up with them? I had other problems when trying to go the closure route (namely that I would then have to closure-ify my entire project to get things working). |
|
I think it depends on your definition of "handle" :) For all the static type analysis closure needs to have static understanding of where each module lives and what symbols are defined on it. I am guessing closure can handle CJS for basic minification tasks, but not for stricter type checking, which must be turned on by one of the flags inside clutz. It is all a guess on my part since all the use cases I have at hand are closure annotated code as input to clutz. My recommendation is trying to feed your project into closure independent of clutz, as you will have more documentation and support for that task alone. Once you have done that we can try to replicate with clutz. |
|
Closing this issue, as there is nothing directly actionable in clutz codebase. My take away is that clutz is not a great fit for projects that dont' already go through Closure compiler. |
Howdy!
I'm trying to get clutz integrated into our proto build over in CockroachDB, but I'm running into some trouble. Currently, I'm, compiling our protos to commonjs and trying to run clutz over the output to produce typings. The error I get is below:
This is my first attempt at using any tool in the closure compiler ecosystem, so I'm sure I've done something wrong. Any help would be greatly appreciated!
The text was updated successfully, but these errors were encountered: