v7.17.0

[7.17.0] - 2026-09-05

Fixed

• install-dependencies and create --dependencies now scaffold a working ESLint setup. The template was an .eslintrc.js extending eslint-config-axway/env-alloy, and both installers pulled eslint, eslint-config-axway, and eslint-plugin-alloy unpinned. Three upstream changes broke it at once and nothing reported the failure: eslint 9 stopped reading .eslintrc.*, eslint-config-axway@10.0.0 (Dec 18, 2025) removed the env-alloy and env-titanium environments, and eslint-plugin-alloy has been unmaintained since July 2022 and throws This method cannot be used with flat config the moment eslint 9 loads it. Any project scaffolded since December 2025 got a lint that could not run at all.

Changed

• The shipped template is now eslint.config.mjs, a flat config for eslint 9. It declares the Titanium and Alloy globals itself (Ti, Alloy, $, $model, L, Backbone, OS_*, ENV_*, DIST_*, task, plus the host globals console, alert, and the timer functions), the part of env-alloy that actually mattered. The .mjs extension keeps it valid whether or not the project's package.json sets "type": "module".
• Installers now pull only eslint and @eslint/js. eslint-config-axway no longer serves Alloy projects and eslint-plugin-alloy does not load under eslint 9, so neither is installed.
• The template ignores generated code. Resources/, build/, purgetss/, and the six libraries PurgeTSS itself copies into app/lib/ (fontawesome.js, materialicons.js, materialsymbols.js, framework7icons.js, purgetss.ui.js, purgetss.colors.js). They are listed by name rather than as app/lib/** so the developer's own libraries in that folder keep being linted; in a real project, linting materialsymbols.js alone produced 3,023 of 3,731 reported problems.
• no-unused-vars is a warning, not an error. Alloy binds event handlers from the XML view, so a controller function with no caller in the JS may still be in use. eslint-plugin-alloy used to read the XML to tell those apart; until that gap is closed, a warning avoids failing on handlers that are genuinely wired up.
• The generated images: block now explains where the output sizes come from. Four comment lines above the section state that sources in purgetss/images/ are 4× masters, with the numbers (1024px → 256 (mdpi/@1x), 384 (hdpi), 512 (xhdpi/@2x), 768 (xxhdpi/@3x), 1024 (xxxhdpi)), that there is no width key because the source's own pixels decide it, and that SVGs, which have no natural pixels, are pinned in files. The convention was documented in purgetss images --help and in the official docs, but not in the file where someone reads it while wondering why a 1024px logo came out at 256. The quality comment now also names the formats it does not reach: PNG uses compressionLevel: 9 and GIF takes no quality parameter, so the value only applies to webp, jpeg, avif and tiff. Both copies of the block are updated: the one ensure-images-section.js patches into an existing config, and the one lib/templates/purgetss.config.js.cjs seeds through init.

Added

• The images: section now rejects unknown keys instead of ignoring them. assertKnownImagesKeys() mirrors the validation brand: has had, for the same reason: a qualty: 95 is indistinguishable from the default, so the typo used to produce the wrong output without reporting anything. It checks the five top-level keys (quality, format, autoSync, confirmOverwrites, files) and the three valid keys inside each files[] entry (filename, width, height), reports every problem in one pass with the entry index, and requires filename, since an entry without one matches nothing and was skipped by buildOverridesMap() the same way. Nothing is generated when validation fails. Keys that were never part of the section, such as width, opacity, padding or output, are now named as errors instead of doing nothing.
• tests/unit/core/images-config.test.js covers the validator and both copies of the shipped block. It parses the images: block out of ensure-images-section.js and out of lib/templates/purgetss.config.js.cjs, asserts each one validates against the whitelist, declares the same five keys with the same default values, carries the 4× documentation, and that the two copies are byte-identical once whitespace is normalized. Verified to fail in both directions: editing one copy alone, and dropping a key from the whitelist.
• tests/unit/cli/eslint-template.test.js covers the shipped template. It lints an idiomatic Alloy controller and requires zero problems, lints deliberately non-conforming code and requires semi, quotes, indent, and space-before-function-paren to fire, and asserts the generated libraries are ignored while developer code in app/lib/ is not. The second check is the point: a config that applies no rules would also report zero problems on valid code, which is how the previous template rotted unnoticed. A fourth check reads create.js and dependencies.js and requires that both still copy dist/configs/invisible/eslint.config.mjs and reference none of eslint-config-axway, eslint-plugin-alloy or .eslintrc: the template's filename lives in three places, and renaming it in one would leave a cp that fails inside the user's project while every other test kept passing.