1
0
Fork 0
easejs/tools/combine

188 lines
4.8 KiB
Plaintext
Raw Permalink Normal View History

#!/bin/sh
#
# Copyright (C) 2010, 2011, 2012, 2013, 2014 Free Software Foundation, Inc.
#
# This file is part of GNU ease.js.
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# #
PATH_TOOLS=$( dirname "$0" )
PATH_LIB="$PATH_TOOLS/../lib"
PATH_TEST="$PATH_TOOLS/../test"
MODULE_EXT='js'
TPL_PATH="$PATH_TOOLS/combine.tpl"
2011-05-23 18:59:50 -04:00
TPL_LICENSE_PATH="$PATH_TOOLS/license.tpl"
TPL_TEST_PATH="$PATH_TOOLS/combine-test.tpl"
TPL_VAR='/**{CONTENT}**/'
RMTRAIL="$PATH_TOOLS/rmtrail"
# determine the order in which modules must be concatenated; order matters to
# ensure dependencies are loaded before the module that depends on them
cat_modules=$(
cd "$PATH_TOOLS/../" &&
grep -rIo ' require(.*)' lib/ \
| sed "s/^lib\///;s/\.js://;s/require( *'\.\/\(.*\)'.*/\1/" \
| node tools/combine-order.js
) || {
echo "Failed to get module list" >&2
exit 3
}
# get a list of all available modules
all_modules=$(
cd "$PATH_LIB" &&
ls -1 *.js \
| sed 's/\.js$//'
)
# get lsit of modules that haven't been
remain_modules=$(
echo "$cat_modules
$all_modules" \
| sort \
| uniq -u
)
cat_modules="$cat_modules
$remain_modules"
##
# Output template header
##
tpl_header()
{
2011-05-23 18:59:50 -04:00
# prepend license
cat "$TPL_LICENSE_PATH"
# cut out the top of the template (before the content location)
cat "$TPL_PATH" \
| awk "{
if ( \$0 == \"$TPL_VAR\" )
exit;
else
print \$0;
}"
}
##
# Output template footer
##
tpl_footer()
{
# cut out the bottom of the template (after where we need to place the
# content)
cat "$TPL_PATH" \
| awk "BEGIN { go = 0 }
{
if ( \$0 == \"$TPL_VAR\" )
go = 1
else
if ( go == 1 )
print \$0;
}"
}
2011-05-23 18:59:50 -04:00
# ensure we can locate our templates (should be in the /tools dir)
if [ ! -f "$TPL_PATH" ]; then
echo "Error: combine.tpl not found ($TPL_PATH)" >&2
exit 1
fi
2011-05-23 18:59:50 -04:00
if [ ! -f "$TPL_PATH" ]; then
echo "Error: license.tpl not found ($TPL_PATH)" >&2
2011-05-23 18:59:50 -04:00
exit 1
fi
# output combined file header
tpl_header
# output each of the modules
for module in $cat_modules; do
filename="$PATH_LIB/$module.$MODULE_EXT"
if [ ! -f "$filename" ]; then
echo "Error: module $module not found ($filename)" >&2
exit 2
fi
# each module must be enclosed in a closure to emulate a module
echo "/** $module **/"
echo "( function( module, __dirname )"
echo "{"
echo " var exports = module.exports = {};"
# add the module, removing trailing commas
cat $filename | $RMTRAIL
echo "} )( module['$module'] = {}, '.' );"
done
# include tests?
if [ "$INC_TEST" ]; then
# note that not all tests are included
TEST_CASES=$( cd "$PATH_TEST"; find . -name '*Test*.js' \
| sed 's/^.\///' \
| sort \
| grep -v '\(Combine\(PreEs5\)\?\|Index\)Test.js' \
)
Added very basic formatted output and failure tolerance for test case The one year anniversary of the beginning of the ease.js project is quickly approaching. I find myself to be not quite where I had expected many months ago, but find that the project has evolved so much further than I had event originally anticipated. My main motivation behind the project continues to be making my life at work easier, while providing an excellent library that others can hopefully benefit from. If anything, it's a fascinating experiment and clever hack around JavaScript. Now I find myself with a newborn child (nearly four weeks old), who demands my constant attention (and indeed, it is difficult to find the desire to put my attention elsewhere). Still - I am a hacker. Software is my passion. So the project must move forward. I also find myself unwilling to create a blog for ease.js. I feel it's inappropriate for a project that's in its (relative) infancy and does not have much popularity (it has never been announced to anyone). As such, I feel that commit messages will serve my purpose as useful journal entries regarding the status of the project. They will also be interesting easter eggs for those who would wish to seek them out for additional perspective on the project. (Granted, one could easy script the discovery of such entries by examining the absurd length of the commit message...perhaps the git log manpages would be useful). So. Let's get back to the project. ease.js is currently going through a strong refactoring in order to address design issues that have begun to creep up as the project grew. The initial design was a very simple one - a "series of modules", as it was originally described in a CommonJS sense, that would provide features of a classical Object-Oriented system. It would seem ironic that, having a focus on classical Object-Oriented development, one would avoid developing the project in such a paradigm. Instead, I wished to keep the design simple (because the project seemed simple), more natural to JS developers (prototypal) and performant (object literals do not have the overhead of instantiation). Well, unfortunately, the project scope has increased drastically due to the success of the implementation (and my playfulness), the chosen paradigm has become awkward in itself and the performance benefit is indeed a micro-optimization when compared with the performance of both the rest of the system and the system that will implement ease.js as a framework. You can only put off refactoring for so long before the system begins to trip over itself and stop being a pleasure to work with. In fact, it's a slap in the face. You develop this intricate and beautiful system (speaking collectively and generally, of course) and it begins to feel tainted. In order to prevent it from developing into a ball of mud - a truly unmaintainable mess - the act of refactoring is inevitable, especially if we want to ensure that the project survives and is actively developed for any length of time. In this case, the glaring problem is that each of the modules are terribly, tightly coupled. This reduces the flexibility of the system and forces us to resort to a system riddled with conditionals. This becomes increasingly apparent when we need to provide slightly different implementations between environments (e.g. ES5/pre-ES5, production/development, etc and every combination). Therefore, we need to decouple the modules in order to take advantage of composition in order to provide more flexible feature sets depending on environment. What does this mean? We need to move from object literals for the modules to prototypes (class-like, but remember that ease.js exists because JS does not have "classes"). A number of other prototypes can be extracted from the existing modules and abstracted to the point where they can be appropriately injected where necessary. Rather than using conditions for features such as fallbacks, we can encapsulate the entire system in a facade that contains the features relevant to that particular environment. This will also have the consequence that we can once again test individual units rather than systems. At the point of this commit (this entry was written before any work was done), the major hurdle is refactoring the test cases so that they do not depend on fallback logic and instead simply test specific units and skip the test if the unit (the prototype) is not supported by the environment (e.g. proxies in a pre-ES5 environment). This will allow us to finish refactoring the fallback and environment-specific logic. It will also allow us to cleanly specify a fallback implementation (through composition) in an ES5 environment while keeping ES5 detection mechanisms separate. The remaining refactorings will likely be progressive. This all stemmed out of the desire to add the method hiding feature, whose implementation varies depending on environment. I want to get back to developing that feature so I can get the first release (v0.1.0) out. Refactoring can continue after that point. This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
# find include files separately so we can output those before the tests
TEST_INC=$(
cd "$PATH_TEST" \
&& find . -name 'inc-*.js' \
| sed 's/^\.\///' \
)
Added very basic formatted output and failure tolerance for test case The one year anniversary of the beginning of the ease.js project is quickly approaching. I find myself to be not quite where I had expected many months ago, but find that the project has evolved so much further than I had event originally anticipated. My main motivation behind the project continues to be making my life at work easier, while providing an excellent library that others can hopefully benefit from. If anything, it's a fascinating experiment and clever hack around JavaScript. Now I find myself with a newborn child (nearly four weeks old), who demands my constant attention (and indeed, it is difficult to find the desire to put my attention elsewhere). Still - I am a hacker. Software is my passion. So the project must move forward. I also find myself unwilling to create a blog for ease.js. I feel it's inappropriate for a project that's in its (relative) infancy and does not have much popularity (it has never been announced to anyone). As such, I feel that commit messages will serve my purpose as useful journal entries regarding the status of the project. They will also be interesting easter eggs for those who would wish to seek them out for additional perspective on the project. (Granted, one could easy script the discovery of such entries by examining the absurd length of the commit message...perhaps the git log manpages would be useful). So. Let's get back to the project. ease.js is currently going through a strong refactoring in order to address design issues that have begun to creep up as the project grew. The initial design was a very simple one - a "series of modules", as it was originally described in a CommonJS sense, that would provide features of a classical Object-Oriented system. It would seem ironic that, having a focus on classical Object-Oriented development, one would avoid developing the project in such a paradigm. Instead, I wished to keep the design simple (because the project seemed simple), more natural to JS developers (prototypal) and performant (object literals do not have the overhead of instantiation). Well, unfortunately, the project scope has increased drastically due to the success of the implementation (and my playfulness), the chosen paradigm has become awkward in itself and the performance benefit is indeed a micro-optimization when compared with the performance of both the rest of the system and the system that will implement ease.js as a framework. You can only put off refactoring for so long before the system begins to trip over itself and stop being a pleasure to work with. In fact, it's a slap in the face. You develop this intricate and beautiful system (speaking collectively and generally, of course) and it begins to feel tainted. In order to prevent it from developing into a ball of mud - a truly unmaintainable mess - the act of refactoring is inevitable, especially if we want to ensure that the project survives and is actively developed for any length of time. In this case, the glaring problem is that each of the modules are terribly, tightly coupled. This reduces the flexibility of the system and forces us to resort to a system riddled with conditionals. This becomes increasingly apparent when we need to provide slightly different implementations between environments (e.g. ES5/pre-ES5, production/development, etc and every combination). Therefore, we need to decouple the modules in order to take advantage of composition in order to provide more flexible feature sets depending on environment. What does this mean? We need to move from object literals for the modules to prototypes (class-like, but remember that ease.js exists because JS does not have "classes"). A number of other prototypes can be extracted from the existing modules and abstracted to the point where they can be appropriately injected where necessary. Rather than using conditions for features such as fallbacks, we can encapsulate the entire system in a facade that contains the features relevant to that particular environment. This will also have the consequence that we can once again test individual units rather than systems. At the point of this commit (this entry was written before any work was done), the major hurdle is refactoring the test cases so that they do not depend on fallback logic and instead simply test specific units and skip the test if the unit (the prototype) is not supported by the environment (e.g. proxies in a pre-ES5 environment). This will allow us to finish refactoring the fallback and environment-specific logic. It will also allow us to cleanly specify a fallback implementation (through composition) in an ES5 environment while keeping ES5 detection mechanisms separate. The remaining refactorings will likely be progressive. This all stemmed out of the desire to add the method hiding feature, whose implementation varies depending on environment. I want to get back to developing that feature so I can get the first release (v0.1.0) out. Refactoring can continue after that point. This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
# include test combine template
cat "$TPL_TEST_PATH" | grep -v '^#' | $RMTRAIL
echo "/** TEST CASES **/"
echo "ns_exports.runTests = function()"
echo "{"
Added very basic formatted output and failure tolerance for test case The one year anniversary of the beginning of the ease.js project is quickly approaching. I find myself to be not quite where I had expected many months ago, but find that the project has evolved so much further than I had event originally anticipated. My main motivation behind the project continues to be making my life at work easier, while providing an excellent library that others can hopefully benefit from. If anything, it's a fascinating experiment and clever hack around JavaScript. Now I find myself with a newborn child (nearly four weeks old), who demands my constant attention (and indeed, it is difficult to find the desire to put my attention elsewhere). Still - I am a hacker. Software is my passion. So the project must move forward. I also find myself unwilling to create a blog for ease.js. I feel it's inappropriate for a project that's in its (relative) infancy and does not have much popularity (it has never been announced to anyone). As such, I feel that commit messages will serve my purpose as useful journal entries regarding the status of the project. They will also be interesting easter eggs for those who would wish to seek them out for additional perspective on the project. (Granted, one could easy script the discovery of such entries by examining the absurd length of the commit message...perhaps the git log manpages would be useful). So. Let's get back to the project. ease.js is currently going through a strong refactoring in order to address design issues that have begun to creep up as the project grew. The initial design was a very simple one - a "series of modules", as it was originally described in a CommonJS sense, that would provide features of a classical Object-Oriented system. It would seem ironic that, having a focus on classical Object-Oriented development, one would avoid developing the project in such a paradigm. Instead, I wished to keep the design simple (because the project seemed simple), more natural to JS developers (prototypal) and performant (object literals do not have the overhead of instantiation). Well, unfortunately, the project scope has increased drastically due to the success of the implementation (and my playfulness), the chosen paradigm has become awkward in itself and the performance benefit is indeed a micro-optimization when compared with the performance of both the rest of the system and the system that will implement ease.js as a framework. You can only put off refactoring for so long before the system begins to trip over itself and stop being a pleasure to work with. In fact, it's a slap in the face. You develop this intricate and beautiful system (speaking collectively and generally, of course) and it begins to feel tainted. In order to prevent it from developing into a ball of mud - a truly unmaintainable mess - the act of refactoring is inevitable, especially if we want to ensure that the project survives and is actively developed for any length of time. In this case, the glaring problem is that each of the modules are terribly, tightly coupled. This reduces the flexibility of the system and forces us to resort to a system riddled with conditionals. This becomes increasingly apparent when we need to provide slightly different implementations between environments (e.g. ES5/pre-ES5, production/development, etc and every combination). Therefore, we need to decouple the modules in order to take advantage of composition in order to provide more flexible feature sets depending on environment. What does this mean? We need to move from object literals for the modules to prototypes (class-like, but remember that ease.js exists because JS does not have "classes"). A number of other prototypes can be extracted from the existing modules and abstracted to the point where they can be appropriately injected where necessary. Rather than using conditions for features such as fallbacks, we can encapsulate the entire system in a facade that contains the features relevant to that particular environment. This will also have the consequence that we can once again test individual units rather than systems. At the point of this commit (this entry was written before any work was done), the major hurdle is refactoring the test cases so that they do not depend on fallback logic and instead simply test specific units and skip the test if the unit (the prototype) is not supported by the environment (e.g. proxies in a pre-ES5 environment). This will allow us to finish refactoring the fallback and environment-specific logic. It will also allow us to cleanly specify a fallback implementation (through composition) in an ES5 environment while keeping ES5 detection mechanisms separate. The remaining refactorings will likely be progressive. This all stemmed out of the desire to add the method hiding feature, whose implementation varies depending on environment. I want to get back to developing that feature so I can get the first release (v0.1.0) out. Refactoring can continue after that point. This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
for testcase in $TEST_INC $TEST_CASES; do
filename="$PATH_TEST/$testcase"
# generate the module name by removing path and extension, then
# prefixing it with "test/"
module="${filename%.*}"
module="test/${module##*test/}"
module_dir=$( dirname "$module" )
# each module must be enclosed in a closure to emulate a module
echo "/** TEST CASE: $testcase **/"
echo "( function( module, __dirname )"
echo "{"
echo " var exports = module.exports = {};"
# write out current test to make debugging easier in browsers with very
# little debugging support
echo " document.write( '$module...<br />' )"
# add the module, removing trailing commas
cat $filename | $RMTRAIL
echo "} )( module['$module'] = {}, '$module_dir' );"
done
echo "};"
fi
# output combined file footer
tpl_footer
exit 0