build issues with dojo 1.16

[nicolasiac]

using version 1.3.0 gives the following errors in the build. version 1.2.1 does not.

error(307) Failed to evaluate module tagged as pure AMD (fell back to processing with regular expressions). module: dgrid/css/nodes/color-image; error: TypeError: Cannot read property 'nodes' of undefined error(307) Failed to evaluate module tagged as pure AMD (fell back to processing with regular expressions). module: dgrid/css/nodes/gradient; error: TypeError: Cannot read property 'nodes' of undefined error(307) Failed to evaluate module tagged as pure AMD (fell back to processing with regular expressions). module: dgrid/css/nodes/vendor-helpers; error: ReferenceError: module is not defined

[msssk]

Can you test and verify that the only change in the project is between dgrid versions 1.2.1 and 1.3.0? Can you share your build config? I am unable to reproduce this, so if you could provide a test case that would also be helpful.

Are the errors causing the build process to fail, or does it still complete and provide a working application?

A few observations:

• the modules generating errors come from nib. While dgrid 1.3.0 updated its nib dependency from 1.0.4 to 1.1.0, those files did not change from 1.0.4 to 1.1.0
• the modules are only used by Stylus when running Stylus to compile Stylus files to CSS and should not be included in a Dojo build

[nicolasiac]

Yes, that is the only change.

`#!/usr/bin/env bash

set -e

Base directory for this entire project

BASEDIR=$(cd $(dirname $0) && pwd)

Source directory for unbuilt code

SRCDIR="$BASEDIR/src"

Directory containing dojo build utilities

TOOLSDIR="$SRCDIR/util/buildscripts"

Destination directory for built code

DISTDIR="$BASEDIR/dist"

Main application package build configuration

PROFILE="$BASEDIR/profiles/app.profile.js"

Configuration over. Main application start up!

if [ ! -d "$TOOLSDIR" ]; then echo "Can't find Dojo build tools -- did you initialise submodules? (git submodule update --init --recursive)" exit 1 fi

if [ ! -d node_modules ]; then echo "Can't find Node.js dependencies -- did you install them? (npm install)" exit 1 fi

echo "Building application with $PROFILE to $DISTDIR."

echo -n "Cleaning old files..." rm -rf "$DISTDIR" echo " Done"

node_modules/.bin/stylus -c "$SRCDIR/app/resources/app.styl"

"$TOOLSDIR/build.sh" --profile "$PROFILE" --releaseDir "$DISTDIR" $@

cd "$BASEDIR"

Copy & minify index.html to dist

cat "$SRCDIR/index.html" | \ perl -pe 's/\/\/.$//gm; # Strip JS comments' | perl -pe 's/\n/ /g; # Replace newlines with whitespace' | perl -pe 's/<!--.?-->//g; # Strip HTML comments' | perl -pe 's/isDebug: *true,//; # Remove isDebug' > "$DISTDIR/index.html"

perl -pe 's/\s+/ /g; # Collapse whitespace' > "$DISTDIR/index.html"

echo "Build complete" read -p "Press enter to exit"`

[msssk]

Can you provide the app.profile.js you are using? If the project is shareable that would help a lot, if not, a simplified test case would also be very helpful.

[nicolasiac]

Here it is. The project is private and confidential so I cannot share much.

var profile = { //basePathis relative to the directory containing this profile file; in this case, it is being set to the // src/ directory, which is the same place as thebaseUrl` directory in the loader configuration. (If you change // this, you will also need to update run.js.) basePath: '../src/',

// This is the directory within the release directory where built packages will be placed. The release directory
// itself is defined by `build.sh`. You should probably not use this; it is a legacy option dating back to Dojo
// 0.4.
// If you do use this, you will need to update build.sh, too.
// releaseName: '',

// Builds a new release.
action: 'release',

// Strips all comments and whitespace from CSS files and inlines @imports where possible.
cssOptimize: 'comments',

// Excludes tests, demos, and original template files from being included in the built version.
mini: true,

// Uses Closure Compiler as the JavaScript minifier. This can also be set to "shrinksafe" to use ShrinkSafe,
// though ShrinkSafe is deprecated and not recommended.
// This option defaults to "" (no compression) if not provided.
optimize: 'closure',

// We're building layers, so we need to set the minifier to use for those, too.
// This defaults to "shrinksafe" if not provided.
layerOptimize: 'closure',

// A list of packages that will be built. The same packages defined in the loader should be defined here in the
// build profile.
packages: [
    // Using a string as a package is shorthand for `{ name: 'app', location: 'app' }`
    {
        name: 'app', location: 'app', trees: [
                      //exclude .hidden, TestFlat
                      [".", ".", /(\/\.)|(~$)|(TestFlat|dropzone)/]
        ]
    },
    'extResources',
    'dijit',
    'dojo',
    'dojox',
    'dgrid',
    'dstore',
    'ckeditor',
    'event-source-polyfill'
],

// Strips all calls to console functions within the code. You can also set this to "warn" to strip everything
// but console.error, and any other truthy value to strip everything but console.warn and console.error.
// This defaults to "normal" (strip all but warn and error) if not provided.
stripConsole: 'all',

// The default selector engine is not included by default in a dojo.js build in order to make mobile builds
// smaller. We add it back here to avoid that extra HTTP request. There is also an "acme" selector available; if
// you use that, you will need to set the `selectorEngine` property in index.html, too.
selectorEngine: 'lite',

// Any module in an application can be converted into a "layer" module, which consists of the original module +
// additional dependencies built into the same file. Using layers allows applications to reduce the number of HTTP
// requests by combining all JavaScript into a single file.

layers: {
    // This is the main loader module. It is a little special because it is treated like an AMD module even though
    // it is actually just plain JavaScript. There is some extra magic in the build system specifically for this
    // module ID.
    'dojo/dojo': {
        // By default, the build system will try to include `dojo/main` in the built `dojo/dojo` layer, which adds
        // a bunch of stuff we do not want or need. We want the initial script load to be as small and quick to
        // load as possible, so we configure it as a custom, bootable base.
        boot: true,
        customBase: true
    },

    // In this demo application, we load `app/main` on the client-side, so here we build a separate layer containing
    // that code. (Practically speaking, you would probably just want to roll everything into the `dojo/dojo` layer,
    // but this helps provide a basic illustration of how multi-layer builds work.) Note that when you create a new
    // layer, the module referenced by the layer is always included in the layer (in this case, `app/main`), so it
    // does not need to be explicitly defined in the `include` array. 

    'app/main': {
        include: ['app/widgets/Inbox/InboxBase/InboxBase', 'app/widgets/core/DTBaseWidget/DTBaseWidget', 'app/widgets/PageBuilder/PageBuilder',
            'app/widgets/core/DTNumberTextBox/DTNumberTextBox', 'app/widgets/core/DTLOV/DTLOV', 'app/widgets/core/DTText/DTText',
            'app/widgets/core/DTTextArea/DTTextArea']
    },

    // admin layers
    'app/widgets/Admin/AdminLanding/AdminLanding': { exclude: ['app/main', 'ckeditor/ckeditor'] }
},

// Providing hints to the build system allows code to be conditionally removed on a more granular level than simple
// module dependencies can allow. This is especially useful for creating tiny mobile builds. Keep in mind that dead
// code removal only happens in minifiers that support it! Currently, only Closure Compiler to the Dojo build system
// with dead code removal. A documented list of has-flags in use within the toolkit can be found at
// <http://dojotoolkit.org/reference-guide/dojo/has.html>.
staticHasFeatures: {
    // The trace & log APIs are used for debugging the loader, so we do not need them in the build.
    'dojo-trace-api': false,
    'dojo-log-api': false,

    // This causes normally private loader data to be exposed for debugging. In a release build, we do not need
    // that either.
    'dojo-publish-privates': false,

    // This application is pure AMD, so get rid of the legacy loader.
    'dojo-sync-loader': false,

    // `dojo-xhr-factory` relies on `dojo-sync-loader`, which we have removed.
    'dojo-xhr-factory': false,

    // We are not loading tests in production, so we can get rid of some test sniffing code.
    'dojo-test-sniff': false
}

};`

[msssk]

The nib and nodes folders in dgrid/css/ are not necessary and can be deleted. They have never been present in the dgrid repository - I think at some point the Stylus build process used to create them, but I don't think current versions of Stylus and nib create those folders at all. Can you try deleting dgrid/css/nodes (and dgrid/css/nib if it exists) and run the build?

[nicolasiac]

Now the error changed to error(307) Failed to evaluate module tagged as pure AMD (fell back to processing with regular expressions). module: dgrid/html-report/prettify; error: ReferenceError: window is not defined module: dgrid/html-report/sorter; error: ReferenceError: window is not defined

[msssk]

@nicolasiac If you are able to test with the fix in #1454 it would be much appreciated!