🐛 Bugfix: Why did 'nx build libs-ux-ux-resize' fail with ENOENT, and w...

Date: 2026-03-04
Time: 16:35:07 UTC
Session: gspace1-175.12
Agent: angular
Confidence: 97%
Status: ✅ Documented

📋 Decision Context

Question:

Why did 'nx build libs-ux-ux-resize' fail with ENOENT, and what is the correct naming convention for libs-ux NX libraries?

Task: Session 175: Fix NX library naming convention — build script path resolution

🎯 Decision Made

Chosen:

Renamed NX project from 'libs-ux-ux-resize' to 'ux-resize-lib'. Changed build command from 'build-angular-library.js libs-ux-ux-resize' to 'build-angular-library.js libs-ux/ux-resize'. The build script resolves paths by searching libs/{subDir}/{libName} — the argument must be the relative path under libs/, not the concatenated project name.

Options Considered:

1. Fix project name to ux-resize-lib and build command to libs-ux/ux-resize (chosen)
2. Rename folder to match the flat project name
3. Modify build-angular-library.js to handle hyphenated nested paths
4. Use ng-packagr directly instead of custom build script

💭 Reasoning

Root cause: the custom build script (build-angular-library.js) at line 94-102 searches libs/{subDir}/{libName} for nested libraries. When the argument is 'libs-ux-ux-resize', it looks for libs/libs-ux/libs-ux-ux-resize/ which doesn't exist (folder is ux-resize). The correct convention (verified from ux-panel, ux-portal) is: project name = folder name (e.g., 'ux-panel'), build argument = 'libs-ux/ux-panel' (parent/folder). For our library: project name = 'ux-resize-lib' (user requested -lib suffix), build argument = 'libs-ux/ux-resize'. Early warning: always check existing project.json files in the same parent directory before creating a new library.

📁 Files Involved

• libs/libs-ux/ux-resize/project.json
• tools/scripts/build/build-angular-library.js

🔗 Related

• Decision ID: dev_1772642107665_n7gt185
• Session: 175
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation