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
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.
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
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)
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.
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.
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.
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.
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.
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.
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.
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.
we should use branches to make sure the profiles built are appropriate for the different levels of dojo.
Simplify use of DOH by creating a DOH (browser) layer as part of the DBF build.
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?
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.