Path[1] argument must be of type string. Received undefined

[esmayl]

Command

extract-i18n

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

I have been trying to export the i18n information from a part of our code, previously this code was in our project as components.
Now I want to create a library out of it and the actual building and using it in the project as a package works but when exporting with ng extract-i18n --project <projectNameHere> I keep getting the error from the title:

An unhandled exception occurred: The "paths[1]" argument must be of type string. Received undefined

In debugging the offending line and file I've found that the actual object used in this process has the path variable but it's an object.

Changing this to an array or just a string does not resolve the issue and even breaks the actual build of the library.

I've reproduced this in a brand new project and still the same error.

Minimal Reproduction

Create a new workspace, add a library and try to extract localization info

• ng new company.Angular.Components --no-create-application
• cd .\company.Angular.Components\
• ng generate library @company/angular-lib-forms
• ng add @angular/localize
• ng extract-i18n --project @company/angular-lib-forms

Exception or Error

[error] TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined
    at Object.resolve (node:path:171:9)

    at getCommonConfig (C:\Users\<username>\Desktop\Projects\<projectname>\node_modules\@angular-devkit\build-angular\src\tools\webpack\configs\common.js:275:24)

    at async Promise.all (index 2)

    at async generateWebpackConfig (C:\Users\<username>\Desktop\Projects\<projectname>\node_modules\@angular-devkit\build-angular\src\utils\webpack-browser-config.js:64:22)

    at async generateBrowserWebpackConfigFromContext (C:\Users\<username>\Desktop\Projects\<projectname>\node_modules\@angular-devkit\build-angular\src\utils\webpack-browser-config.js:119:20)

    at async extractMessages (C:\Users\<username>\Desktop\Projects\<projectname>\node_modules\@angular-devkit\build-angular\src\builders\extract-i18n\webpack-extraction.js:52:24)

    at async execute (C:\Users\<username>\Desktop\Projects\<projectname>\node_modules\@angular-devkit\build-angular\src\builders\extract-i18n\builder.js:84:28)

Your Environment

Angular CLI: 18.1.2
Node: 20.15.0
Package Manager: npm 10.7.0
OS: win32 x64

Angular: 18.1.1
... animations, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1801.2
@angular-devkit/build-angular   18.1.2
@angular-devkit/core            18.1.2
@angular-devkit/schematics      18.1.2
@angular/cli                    18.1.2
@schematics/angular             18.1.2
ng-packagr                      18.1.0
rxjs                            7.8.1
typescript                      5.5.4
zone.js                         0.14.8

Anything else relevant?

No response

[dgp1130]

I know our library i18n story hasn't been very well fleshed out so I think this might just be a known issue (albeit with a bad error message). I couldn't find any explict docs on this, but #17140 implies library i18n isn't supported in the CLI.

I took a quick look but found that ng add @angular/localize does not add an extract-i18n target, so the repro doesn't work. After adding one I was able to reproduce:

"extract-i18n": {
  "builder": "@angular-devkit/build-angular:extract-i18n",
  "options": {
    "buildTarget": "@wksp/my-lib:build"
  }
},

(Side note: @angular/build:extract-i18n did not work and threw "Either browser or at least one entryPoints value must be provided". Also JSON schema intellisense doesn't like buildTarget and claims that property doesn't exist on @angular-devkit/build-angular:extract-i18n.)

The error seems to be coming from this line. paths[1] refers to buildOptions.outputPath which comes from Webpack. I don't think ng-packagr uses Webpack at all which reinforces my thinking that library message extraction hasn't worked in the past.

That said, there's probably an opportunity for at least a better error message here. If buildTarget points at a ng-packagr target, we should fail with a clean message. ng add @angular/localize --project some-lib should also probably fail with an error.