You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unable to generate a scoped library with v6 rc0 #10172
Try to generate a library with a scoped name: ng g library @xxx/core
Observed behavior
It throws the following error in the shell:
Could not find an NgModule. Use the skip-import option to skip importing in NgModule.
Desired behavior
It should generate a library named @xxx/core in the folder projects/xxx-core or maybe projects/xxx/core or even projects/core with the correct package name @xxx/core in the package.json file.
If it's not possible, then it should throw an error message that explains that it doesn't support scoped package names.
I suggest to generate a folder structure where the package name is a correct directory path structure - similar to how scoped packages are installed into the node_modules folder.
So when generating a scoped package with ng g library @xxx/core where the package name in package.json will be @xxx/core CLI should generate a folder structure
|-@xxx
|-core
|-package.json
Not only would it be compatible with npm layout. It is likely to work better with VSCode's auto-import suggestions. For example consider a monorepo folder structure similar to the Angular repos. You would probably generate a library in the packages folder then.
Now if you attempt to use a class Foo exported by index.ts of package @foo/bar you ideally want
VSCode to suggest an absolute import
import {Foo} from "@foo/bar";
I've been successful to make this work in VSCode 1.19 but it temporarily stopped working in 1.20 or 1.21 after some refactorings in VSCode. Absolute path imports should be working again with latest VSCode versions and with TS 2.8. once microsoft/TypeScript#22249 is resolved (see also microsoft/vscode#43575)
VSCode auto-import with absolute paths required some prerequisites in 1.19:
@foo/bar must be a valid path in the directory referenced via baseUrl in tsconfig.json
@foo/bar must be declared as a dependency in the importing package's package.json (that of @xxx/core)
baseUrl and a generic path mapping must be set in tsconfig.json
Generating the full package name as a directory structure would also make it easier to compile an application from a monorepo structure. For example you could make webpack resolve "@foo/bar" from the packages folder by configuring
in your webpack config. Then you can compile and bundle libs in the monorepo into an application without having to link them with npm link at all because TS and webpack can directly resolve them from packages rather than node_modules.
@gms1 Brocco has answered the reasoning in one of the commit discussions. They drop the @ because it causes problems with path auto-completion on mac and windows console terminals, which they want to provide to users working a lot on the terminal (or from within VSCode e.g.).
As far as I understood instead of a generic path mapping (which would be possible when sticking to package name convention) the CLI will generate a path mapping for each lib in tsconfig.json which maps a package import path including the @ onto a filesystem path without the @. So eventually, there will be no difference in how you would import a package in source code. Writing import from "@foo/bar" will work.
I see the logic made it up but I'm unable to generate a new project with a scope:
➜ ng new "@foo/bar"
Schematic input does not validate against the Schema: {"name":"@foo/bar","version":"6.1.2","newProjectRoot":"projects","skipInstall":false,"linkCli":false,"skipGit":false,"commit":null}
Errors:
Data path ".name" should match format "html-selector".
Is this as expected for now or should I open a separate issue?
This does however function with ng g library @foo/bar, generating ./projects/foo/bar with a properly scoped package name.
Reacted by Andrey Kolkov
angular-automatic-lock-bot commented on Sep 8, 2019
Activity
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
about-code commentedon Apr 7, 2018
I suggest to generate a folder structure where the package name is a correct directory path structure - similar to how scoped packages are installed into the
node_modulesfolder.So when generating a scoped package with
ng g library @xxx/corewhere the package name inpackage.jsonwill be@xxx/coreCLI should generate a folder structureNot only would it be compatible with npm layout. It is likely to work better with VSCode's auto-import suggestions. For example consider a monorepo folder structure similar to the Angular repos. You would probably generate a library in the
packagesfolder then.Now if you attempt to use a class
Fooexported byindex.tsof package@foo/baryou ideally wantVSCode to suggest an absolute import
import {Foo} from "@foo/bar";I've been successful to make this work in VSCode 1.19 but it temporarily stopped working in 1.20 or 1.21 after some refactorings in VSCode. Absolute path imports should be working again
with latest VSCode versions and with TS 2.8.once microsoft/TypeScript#22249 is resolved (see also microsoft/vscode#43575)VSCode auto-import with absolute paths required some prerequisites in 1.19:
@foo/barmust be a valid path in the directory referenced viabaseUrlintsconfig.json@foo/barmust be declared as a dependency in the importing package'spackage.json(that of@xxx/core)baseUrland a generic path mapping must be set intsconfig.jsonExample
tsconfig.jsonGenerating the full package name as a directory structure would also make it easier to compile an application from a monorepo structure. For example you could make webpack resolve
"@foo/bar"from thepackagesfolder by configuringin your webpack config. Then you can compile and bundle libs in the monorepo into an application without having to link them with
npm linkat all because TS and webpack can directly resolve them frompackagesrather thannode_modules.fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
gms1 commentedon Apr 22, 2018
Ideally, the directory should be configurable regardless of the package name
Anyway,
@foo/baris a valid package name and a valid directory subtree. Why is this hocus-pocus with the directory name needed at all?see
Brocco/devkit@6996de1
fix(@schematics/angular): Allow for scoped library names
1 remaining item
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
fix(@schematics/angular): Allow for scoped library names
about-code commentedon Apr 25, 2018
@gms1 Brocco has answered the reasoning in one of the commit discussions. They drop the
@because it causes problems with path auto-completion on mac and windows console terminals, which they want to provide to users working a lot on the terminal (or from within VSCode e.g.).As far as I understood instead of a generic path mapping (which would be possible when sticking to package name convention) the CLI will generate a path mapping for each lib in
tsconfig.jsonwhich maps a packageimportpath including the@onto a filesystem path without the@. So eventually, there will be no difference in how you wouldimporta package in source code. Writingimport from "@foo/bar"will work.about-code commentedon Apr 25, 2018
@gms1 See here angular/devkit#646 (comment)
fix(@schematics/angular): Allow for scoped library names
CharlyRipp commentedon Aug 2, 2018
I see the logic made it up but I'm unable to generate a new project with a scope:
Is this as expected for now or should I open a separate issue?
This does however function with
ng g library @foo/bar, generating./projects/foo/barwith a properly scoped package name.angular-automatic-lock-bot commentedon Sep 8, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.