pruzand / dojo-build-factory Goto Github PK
View Code? Open in Web Editor NEWA project to build and/or host ready-to-use dojo builds for predefined configuration (e.g. a ready to use dojox.mobile layer).
License: Other
A project to build and/or host ready-to-use dojo builds for predefined configuration (e.g. a ready to use dojox.mobile layer).
License: Other
The goal of this project is to simplify getting started with Dojo, by greatly decreasing the number of files and concepts needed to become productive. Gone are the days of sorting through 20,000 files and their dependencies that might be needed to use Dojo. * pre-defined, built/optimized layers for common sub packages of Dojo (a more logical mapping than the current fragmented projects. All Javascript files included in the pre optimized layers are removed from the build output, greatly reducing the overall number of JavaScript files needed to get started. * pre-packaged themes (css files & associated resources) for mobile and desktop which have individual .css files rolled up into aggregate CSS layer that's easy to include in HTML pages. * pre-packaged localization bundles (multiple bundles, one per language, per major sub package of dojo) The plan is to have prebuilt packages for the following dojo area: AMD Loader (minimal, 4k) Full Core Common UI F/W Desktop UI (dijit) Desktop Theme: Claro (claro)(cross-platform)(optimized) Mobile UI (dojox/mobile) Mobile Theme: iOS (iPad/iPhone)(optimized) Mobile Theme: Android (2.1-3.x)(optimized) Mobile Theme: Blackberry (OS6)(optimized) Mobile Theme: Mobile One UI (future)(cross-platform)(optimized) Vector Graphics API (dojox/gfx) Business Charting (dojox/charting and it's dependencies, with a single default nice looking theme) Grid (gridx) Gauges (dgauges) Calendar (dojox/calendar) Treemap (dojox/treemap) Language packs Please refer to https://github.com/pruzand/Dojo-Build-Factory/wiki for more information about this project and how to use it. License: The Dojo Build Factory project is published under the terms of the Dojo License.
in addition to the current dojo/dojo.js, create dojo/nano.js as part of the build output. This will require running yet another build pass to produce.
all .less files should be stripped from the build output dirs...there are still some inside dijit/themes/claro directory.
Also, the although the claro theme gets minified properly (claro.css), the loose files that are included in that theme still remain in the output.
maybe it's because I ran the build against 1.8, but there are still a bunch of .uncompressed.js suffixed files in both the compressed and uncompressed results directories. Expecting there to be no files in any results directory with that suffix.
I was looking into why the uncompressed dojo.js is still 245kb (seems waaay too big) and noticed that there are still code blocks like the following written inline:
if( 0 ){
var trace = req.trace = function(
group, // the trace group to which this application belongs
args // the contents of the trace
){
///
// Tracing interface by group.
//
// Sends the contents of args to the console iff (req.trace.on && req.trace[group])
if(trace.on && trace.group[group]){
signal("trace", [group, args]);
for(var arg, dump = [], text= "trace:" + group + (args.length ? (":" + args[0]) : ""), i= 1; i<args.length;){
arg = args[i++];
if(isString(arg)){
text += ", " + arg;
}else{
dump.push(arg);
}
}
req.log(text);
dump.length && dump.push(".");
req.log.apply(req, dump);
}
};
mix(trace, {
on:1,
group:{},
set:function(group, value){
if(isString(group)){
trace.group[group]= value;
}else{
mix(trace.group, group);
}
}
});
trace.set(mix(mix(mix({}, defaultConfig.trace), userConfig.trace), dojoSniffConfig.trace));
on("config", function(config){
config.trace && trace.set(config.trace);
});
This entire code block is essentially "dead code" that can never be executed (because of the if(0) conditional). Isn't there an option in closure compiler to remove these dead code branches... or is that not being used for the uncompressed branch?
there are additional .compressed.js files that can be removed under:
uncompressed/dojo/nls (and subdirs)
uncompressed/dojo/cldr/nls (and subdirs)
uncompressed/dijit/nls
uncompressed/dijit/form/nls
uncompressed/dijit/_editor/nls (and subdirs)
Why are the following files remaining after the build?
dijit/tree/ObjectStoreModel.js
_tree/dndSource.js
It seems that these should be built into the dijit layer by default and not appear in the output dirs.
Builds are being executed with template inlining, so inside the digit-layer.js for example there is this kind of code:
....
'url:dijit/templates/CheckedMenuItem.html':"<tr class="dijitReset dijitMenuItem" data-dojo-attach-point="focusNode" role="menuitemcheckbox" tabIndex="-1">\n\t<td class="dijitReset dijitMenuItemIconCell" role="presentation">\n\t\t<img src="${blankGif}" alt="" class="dijitMenuItemIcon dijitCheckedMenuItemIcon" data-dojo-attach-point="iconNode"/>\n\t\t<span class="dijitCheckedMenuItemIconChar">โ\n\t\n\t<td class="dijitReset dijitMenuItemLabel" colspan="2" data-dojo-attach-point="containerNode,labelNode">\n\t<td class="dijitReset dijitMenuItemAccelKey" style="display: none" data-dojo-attach-point="accelKeyNode">\n\t<td class="dijitReset dijitMenuArrowCell" role="presentation">ย \n\n",
'dijit/form/TextBox':function(){
require({cache:{
'url:dijit/form/templates/TextBox.html':"<div class="dijit dijitReset dijitInline dijitLeft" id="widget${id}" role="presentation"\n\t><div class="dijitReset dijitInputField dijitInputContainer"\n\t\t><input class="dijitReset dijitInputInner" data-dojo-attach-point='textbox,focusNode' autocomplete="off"\n\t\t\t${!nameAttrSetting} type='${type}'\n\t/></div\n>\n"}});
define("dijit/form/TextBox", [
"dojo/_base/declare", // declare
"dojo/dom-construct", // domConstruct.create
"dojo/dom-style", // domStyle.getComputedStyle
"dojo/_base/kernel", // kernel.deprecated
"dojo/_base/lang", // lang.hitch
"dojo/sniff", // has("ie") has("mozilla")
"./_FormValueWidget",
"./_TextBoxMixin",
"dojo/text!./templates/TextBox.html",
"../main" // to export dijit._setSelectionRange, remove in 2.0
], function(declare, domConstruct, domStyle, kernel, lang, has,
_FormValueWidget, _TextBoxMixin, template, dijit){
...
So the contents of these template files have been inlined into the layer file already. Having them inside the templates folder is unnecessary.
url:dijit/templates/CheckedMenuItem.html
url:dijit/form/templates/TextBox.html
If we can verify that all the templates files for the dijit layer are already included, we can simply delete the dijit/templates directory.
Not sure if there's a better way to detect this during the build (seems similar to the .css @import loose css file issue). We should open tickets for both and discuss with Rawld for better ways to get this info out of the build so that we don't create a fragile process here.
dojox projects that follow dijit Templated widget conventions will have the same issue.
This file looks like it's just around for api doc purposes and is the only file in that directory.
Consider removing the dijit/resources directory altogether from the builds if there's nothing useful there.
The Rich Text Editor in digit has many plugins under dijit/_editor/plugins that can be baked into a single layer.
An additional set of editor editor extensions are inside dojox/editor and could be built into a second new layer: dijit-editor-plugins-ext
Missing profile layer vars for some of the dijit's that have been skinned for mobile use:
The first two I see are:
Calendar
ColorPicker
If you include the full desktop layer, apps will work, but mobile devs wont want to include all of dijit for just the few mobile themed dijits (used in the Opener tests/demos). At the same time, these are probably not commonly-used components, so we dont always want to carry the overhead of putting them into the standard mobile layer.
I think a decent trade-off would be to define layer vars for each of these, so that if someone wants to create a custom build that includes them in their mobile layer, it should be very easy to just reference the layer var for the components they need.
Simplify use of DOH by creating a DOH (browser) layer as part of the DBF build.
Make it easy for people to download individual packages of the build output, by creating build output zip files for each "package" being built. There should be a zip for each "theme" for example, so that one can download just the pieces needed. These zip's can be referenced from the main landing pages on the dojo website, so that evaluators can get a download of just the individual pre-built parts of dojo for the subproject they're interested in.
Checkin these zips to github so that the pre-built versions can be grabbed without having to setup and run the build yourself.
we should use branches to make sure the profiles built are appropriate for the different levels of dojo.
The build is doing template inlining by default, so the following directories can be removed from the uncompressed and compressed output dirs:
dijit/templates/
dijit/layout/templates/
dijit/form/templates/
also all templates/ directories under dojox subprojects can be removed.
Currently, you have to manually prune the following dijit theme directories to reduce disk footprint:
By default, the build should just include "claro" theme in the dijit/themes folder.
It would be good to have an option to override claro and provide a list of the theme folder names to include on the command line
Since the dojo/parser is already included in the core web layer, there is no reason to also have the dojox/mobile/parser in the standard mobile layer. The dojo parser is more feature rich. We should comment the mobile parser out of the mobile.js profile with a note that if it is included the core web dojo/parser should not be used at the same time.
There are a lot of modules built into dojo.js other than amd loader...this is unexpected.
I thought that dojo.js would only include AMD loader (with sync compatibility features included for now), but that the other non-AMD loader base and core modules would only be in the core layer.
We need to inspect the contents of both of these layers and make sure they have the contents we're expecting.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.