jizy-builder

Per-site × per-context client-bundle concatenator.

Since the JiZy ecosystem was de-composed into standalone packages, every piece already ships a prebuilt IIFE dist that sets its own browser global (jizy-factory→JiZy, jizy-dom→jDOM / jDOMplugin / jDOMcreate, jizy-modalizer→Modalizer, plus jizy-cooky, jizy-browser, …). So a client bundle no longer needs rollup — it just needs the right files concatenated in dependency order. This tool does exactly that: it reads a config and writes one un-minified jizy-<context>.js (+ matching .css).

Globals stay à-la-carte — no re-namespacing under a single JiZy. Each module dist sets its global first; dom-plugin raw scripts run next (they call jDOMplugin(...) and reference jDOM / JiZy / Dropzone as globals); shared-layer and site JS run last.

Use

node node_modules/jizy-builder/cli/build.js --config <abs path to jpack.<context>.js>

The config file must default-export an object:

export default {
    context: 'front',                       // 'front' | 'admin' (banner/labels only)
    site: { name: 'mysite', version: '1.0.0' },

    // Where to find the prebuilt jizy-* packages. Optional:
    //   - packagesRoot set → <packagesRoot>/<name>/dist/js/<name>.min.js
    //   - omitted          → Node resolution from consumerRoot's node_modules
    packagesRoot: '/abs/packages',
    consumerRoot: '/abs/site',              // optional; inferred from the config path

    // Ordered prebuilt dist bundles (each an IIFE → its global). Core first by convention.
    modules: ['jizy-factory', 'jizy-dom', 'jizy-modalizer', 'jizy-cooky', 'jizy-browser'],

    // jizy-dom dom-plugin names → jizy-dom/lib/js/plugins/<name>.js (raw, global-using)
    domPlugins: ['accordion', 'hrefData', 'toggler', 'userDropzone'],

    raw: ['/abs/app/front/js/index.js'],    // optional shared-layer files (raw, in order)
    css: ['/abs/app/front/css/front.css'],  // optional shared/site css (after module css)
    clientJs: '/abs/site/_installer/js/front.js',   // site client JS, raw, appended LAST

    output: '/abs/site/public/jizy-front.js',       // JS out; CSS out = same path .js → .css
};

Module entries

A modules entry is either a bare name (resolved as above) or an explicit object for files that don't follow the convention:

modules: [
    'jizy-factory',
    { name: 'dropzone', js: '/abs/vendor/dropzone.min.js', css: '/abs/vendor/dropzone.min.css' },
]

Concat order (locked)

JS → banner · each modules[i] dist .min.js (config order) · each domPlugins[i] raw script · each raw[i] file · clientJs. Sections are joined with ;\n/* --- <label> --- */\n (the leading ; guards against a prior file with no trailing semicolon).

CSS → banner · each module's .min.css that exists (module order) · each css[i] file. The .css file is only written when at least one CSS source contributes.

Output is not minified: the vendor parts are already .min; the dom-plugin / shared / site parts stay readable. Matches the committed public/jizy-front.js convention (no .min suffix).

Example output head:

/*! mysite front v1.0.0 | [email protected], [email protected], [email protected], [email protected] | built 2026-06-02T... */
;
/* --- module: jizy-factory --- */
!function(t){...sets t.JiZy...}(window);
;
/* --- module: jizy-dom --- */
!function(t){...sets t.jDOM/jDOMplugin/jDOMcreate...}(window);
;
/* --- dom-plugin: accordion --- */
jDOMplugin('accordion', function (params) { ... });
;
/* --- client: front.js --- */
JiZy.log?.debug?.('ready');