I am copying the source of THREE.js from this link, and pasting it into Closure Compiler UI. I have the following options set:
// ==ClosureCompiler==
// #compilation_level ADVANCED_OPTIMIZATIONS
// #language ECMASCRIPT5
// #output_file_name default.js
// ==/ClosureCompiler==
Yet, for some reason, clicking compile only gets this down to 271KB uncompressed.
My question is, THREE.js doesn't seem to have any exports, so why doesn't Closure Compiler trim it out completely with ADVANCED_OPTIMIZATIONS?
I am building a library on top of THREE.js, and would like to utilize Closure Compiler's dead code removal to make the bundle more manageable. What else should I be doing to trim out functions in THREE.js that are never called?
It doesn't appear that three.js is compatible with Closure-compiler's ADVANCED_OPTIMIZATIONS mode.
The over 1800 warnings I got when compiling the source were a pretty big clue as well.
Related
I'm just getting started with Flow, trying to introduce it into an existing Node codebase.
Here are two lines Flow complains about:
import Module from 'module';
const nodeVersion = Number(process.versions.node.split('.')[0]);
The warnings about these lines are, respectively:
module. Required module not found
call of method `split`. Method cannot be called on possibly null value
So it seems like Flow isn't aware of some things that are standard in a Node environment (e.g. process.versions.node is guaranteed to be a string, and there is definitely a Node builtin called module).
But then again, Flow's configuration docs suggest it's Node-aware by default. And I have plenty of other stuff like import fs from 'fs'; which does not cause any warning. So what am I doing wrong?
Module fs works as expected because Flow comes with built-in definitions for it, see declare module "fs" here: https://github.com/facebook/flow/blob/master/lib/node.js#L624
Regarding process.versions.node, you can see in the same file that the versions key is typed as a map of nullable strings, with no mention of the specific node property: versions : { [key: string] : ?string };. So you'll need to either make a PR to improve this definition, or adjust your code for the possibility of that value being null.
I guess the answer about module "module" is obvious now – there are no built-in definitions for that module in Flow in lib/node.js. You could write your own definitions, and optionally send a PR with them to the Flow team. You can also try searching github for these, someone might have done the work already.
That lib directory is very useful by the way, it has Flow definitions for DOM and other stuff as well.
we need to run some code after the compile step. Making things happen after the compile step seems easy:
compile in Compile <<= (compile in Compile) map{x=>
// post-compile work
doFoo()
x
}
but how do you run something in the freshly compiled code?
More info on the scenario: we are using less for css in a lift project. We wanted lift to compile less into css on the fly (if needed) to help dev, but produce less using the same code, during the build, before tests etc run. less-sbt may help but we are interested in how to solve this generally.
You can use the triggeredBy method like this:
yourTask <<= (fullClasspath in Runtime) map {classpath =>
val loader: ClassLoader = ClasspathUtilities.toLoader(classpath.map(_.data).map(_.getAbsoluteFile))
loader.loadClass("your.class.Here").newInstance()
} triggeredBy(compile in Compile)
This will instantiate your class that has just been compiled, using the runtime classpath for your application, after any compile.
It would probably help if you explained your use scenario for this, since there are some different possible solution paths here and choosing between them might involve considerations that you haven't told us.
You won't be able to just write down an ordinary method call into the compiled code. That would be impossible since at the time your build definition is compiled, sbt hasn't looked at your project code yet.
Warning: rambling and thinking out loud ahead.
One trick I can suggest is to access testLoader in Test to get a classloader in which your compiled classes are loaded, and then use reflection to call methods there. For example, in my own build I have:
val netlogoVersion = taskKey[String]("...")
netlogoVersion := {
(testLoader in Test).value
.loadClass("org.nlogo.api.Version")
.getMethod("version")
.invoke(null).asInstanceOf[String]
}
I'm not sure whether accessing testLoader in Test will actually work in your case because testLoader loads your test classes as well as your regular classes, so you might get a circular dependency between compile in Compile and compile in Test.
If you want to try to make a classloader that just has your regular classes loaded, well, hmm. You could look in the sbt source code at the implementation of createTestLoader and use it for inspiration, modifying the arguments that are passed to ClasspathUtilities.makeLoader. (You might also look at the similar code in Run.run0. It calls makeLoader as part of the implementation of the run task.)
A different path you might consider is to reuse the machinery behind the run task to run your code. You won't be able to call an arbitrary method in your compiled code this way, only a main method, but perhaps you can live with that, if you don't need a return value back.
The fullRunTask method exists for creating entire run-like tasks. See "How can I create a custom run task, in addition to run?" from http://www.scala-sbt.org/0.13.1/docs/faq.html . fullRunTask makes it very easy to create a separate task that runs something in your compiled code, but by itself it won't get you all the way to a solution because you need a way of attaching that task to the existing compile in Compile task. If you go this route, I'd suggest asking it that last piece as a separate question.
Consider bypassing fullRunTask and just assembling your own call to Run.run. They use the same machinery. In my own build, I currently use fullRunTask, but back before fullRunTask was added by sbt, here was what my equivalent Run.run-based code looked like:
(..., fullClasspath in Compile, runner, streams, ...) map {
(..., cp, runner, s, ...) =>
Run.run("name.of.my.MainClass",
cp.map(_.data), Seq(), s.log)(runner)
}
Pardon the sbt 0.12, pre-macro syntax; this would look nicer if redone with the 0.13 macros.
Anyway, hopefully something in this brain dump proves useful.
I've managed to successfully create an ‘AdminProgram’ which is used to build the installer for my main project. It creates required configs/packages in file system correctly, updates all .xml files and copies all required elements into the correct places before building the installer, which is pretty great.
However, I am now looking to customize my installer to do a little more so that it is able to install a few drivers into the windows registry and at a later date remove existing installs before proceeding with a new one. I have studied the ‘instructions’ ( http://doc-snapshot.qt-project.org/qtifw-1.4/scripting.html#predefined-variables) for some time now and have been unable to quite grasp how exactly these Custom Operations are implemented (where the example code is supposed to be written, how the overridden operations are accessed etc.).
I find that the instruction are a little ambiguous for a programmer as inexperienced as myself and would very much appreciate some help from anyone who can give it?
In order to set entries in the registry you need to add GlobalConfig operations in your component script.
Overload the method Component.prototype.createOperations and add additional commands such as:
function Component() {
'use strict';
}
Component.prototype.createOperations = function () {
'use strict';
// call default implementation
component.createOperations();
component.addOperation("GlobalConfig",
"HKEY_CURRENT_USER\\Software\\#Publisher#\\#ProductName#\\entry",
"key",
"value");
}
The list of operations available are here
I found that some options in CompilerOption are not exported to the command line.
For example, alias all strings is available in the Closure Compiler's Java API CompilerOption but I have no idea how set this in the command line.
I know I can create a new java class, like:
Compiler c = new Compiler();
ComppilerOptions opt = new ComppilerOptions();
opt.setAliasAllString(true);
c.compile(.....);
However I have to handle the command line args myself.
Any simple idea?
============================
In order to try the alias all string option, I write a simple command line application based on compiler.jar.
However I found that, the result I got when open the alias all string is not what I expected.
For example:
a["prototype"]["say"]=function(){
var a="something string";
}
Given the above code, the something string will be replaced by a variable like this:
var xx="something string";
....
var a=xx;
....
This is fine, but how about the string "say"? How does the closure compiler know this should be aliased(replace it use variable) or exported(export this method)?
This is the compiled code now:
a.prototype.say=function(){....}
It seems that it export it.
While I want this:
var a="prototype",b="say",c="something string";
xx[a][b]=function(){.....}
In fact, this is the google_map-like compilation.
Is this possible?
Not all options are available from the command line - this includes aliasAllStrings. For some of them you have the following options:
Build a custom version of the compiler
Use the Java API (see example).
Use plovr
Getting the same level of compression and obfuscation as the Maps API requires code written specifically for the compiler. When properly written, you'll see property and namespace collapsing, prototype aliasing and a whole host of others. For an example of the style of code that will optimize that way, take a look at the Closure Library.
Modifying http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/jscomp/CompilationLevel.java?r=706 is usually easy enough if you just want to play with something.
Plovr (a Closure build tool) provides an option called experimental-compiler-options, which is documented as follows:
The Closure Compiler contains many options that are only available programmatically in Java. Many of these options are experimental or not finalized, so they may not be a permanent part of the API. Nevertheless, many of them will be useful to you today, so plovr attempts to expose these the experimental-compiler-options option. Under the hood, it uses reflection in Java, so it is fairly hacky, but in practice, it is a convenient way to experiment with Closure Compiler options without writing Java code.
I'm in the process of refactoring a Flex application into a "library project", and one of the, err, interesting errors I've come across involves a function like this:
function spam(eggs:*=undefined):void {
...
}
While it was a "Flex application", this function compiled without issue… But when I try to build it as a "library project", the compiler gives me the error:
1047: Parameter initializer unknown or is not a compile-time constant.
So, uuhh… Why? And is there anything I can do to fix that?
There's a bug in jira (link) that says mxmlc and the flash compiler behave differently when working with parameter initializers. As the library projects are compiled using a different compiler (compc in place of mxmlc) I suspect it might be the same issue.
You can probably change the function to something like this, if you need it to be undefined:
function spam(eggs:*=null):void {
if (eggs is null) eggs = undefined;
}
Is the class with this code being used at all? A Flex Project may have optimized it out of the project if it's never used; thus not throwing an error. A library project would not do that.
I would recommend using null as the default value instead of undefined. Isn't there a bit of a paradox to initialize a value as 'undefined' ?