For the Angular framework, packages are scoped under @angular/. like @angular/core. There are cases where Angular exposes a so-called secondary entry-point that provides an additional package.json file for module resolution w/ bundlers. e.g.
The package.json file in core/testing will have the following name to match with the structure that
it follows when pulled by the package manager. i.e. @angular/core/testing. If an API report for such
secondary entry-points is generated using API-extractor, the API extractor will fail with the followed error:
Error: Error parsing the configuration object:
The package name "@angular/core/testing" contains an invalid character: "/"
at Function.prepare (C:\users
It seems unexpected that node-core-library disallows the remaining part of the @scope/{rest} to contain any slashes? In terms of how packages can be published within NPM, this limitation might be correct, but the actual module name (that is also used within the package.json file) seems valid in the ecosystem.
I'm also affected by this issue. Is there a downside to allowing slashes in the {rest} part of the module name? I'm happy to contribute a fix to this issue.
For the Angular framework, packages are scoped under
@angular/
. like@angular/core
. There are cases where Angular exposes a so-called secondary entry-point that provides an additionalpackage.json
file for module resolution w/ bundlers. e.g.The package.json file in
core/testing
will have the following name to match with the structure that it follows when pulled by the package manager. i.e.@angular/core/testing
. If an API report for such secondary entry-points is generated using API-extractor, the API extractor will fail with the followed error:It seems unexpected that
node-core-library
disallows the remaining part of the@scope/{rest}
to contain any slashes? In terms of how packages can be published within NPM, this limitation might be correct, but the actual module name (that is also used within thepackage.json
file) seems valid in the ecosystem.