Two alternatives for more consistent behavior would be:

1. Error on invalid characters which do not match the JSON schema regex
2. Transform both - the project name and the package name to lower case

The second alternative would be more implicit, but also less surprising for folks used to the partial name transform we do right now only for the package name.

Thank you.

I'd like to see #2 as it is more friendly for beginners and for those used to being able to use mixed case project names as they can now.

I am claiming this issue. I have started to work on the fix.

I may be wrong, as I'm not familiar with how angular-cli work under the hood, but if angular uses project name for file structure - lower casing it could lead to bugs.

For example this one: Webpack: “there are multiple modules with names that only differ in casing” but modules referenced are identical see more on StackOverflow.

example:

And by the way a question, @mgechev, although @karthick-manoharan claimed this issue, I was curious to take a look on the angular-cli source code and for now, I event couldn't figure out where the angular.json file generation happens. I succeded to npm link (global) angular-cli, but I have a feeling that I need angular-devkit/core, am I right? Can you give a tip/direction?

@vltansky The fix will be applicable only to the workspace name occurrences in angular.json file. I couldn't relate the StackOverflow issue to this fix. Kindly correct me if i am missing any of your ideas.

My perception is the files under packages/schematics/angular are responsible for angular.json file generation. I have currently applied my changes there and figuring out a way to test it locally.

• .angular.json template
• Workspace options applied to the template

The application schematic adds the project to the workspace using options.name

There's a validateProjectName() function, but it doesn't change the name.

You may want to apply the appropriate string transform function to options.name just after validateProjectName() is called in the default function since options.name feeds into so many other configurations.

@Splaktar Thank you for the pointers. I am leveraging strings.dasherize() method to transform options.name as lower casing the name wont be sufficed as camelcase is not supported as well.
This will match the name as same as in package.json.

In addition to the change in schematics/angular/application/index.ts i was validating if the name transformation needs to be applied for the corresponding individual rules ng-new, app-shell etc. Which i have not found the answers why i should not make the changes in rules.

@karthick-manoharan I can't think of a reason why any of the other schematics would need to be changed in general. The only other schematic that should create a project is the library schematic. Have you tested if that accepts the invalid format?

If you have some other lines of code where you think the name might need to be transformed, feel free to post them here along with your reasoning.

@kyliau @karthick-manoharan How can I help?

using the current version of angular at the time of posting this, there is no fix for the bug ?

There is no fix for the bug ?

I haven't seen any PR for this yet. There's not one linked to this issue.

Somebody has created this somewhat related PR a few hours ago: #17949

Is anybody working on this? Would love to try and make a PR for this. As I understand the issue correct we should lowercase the name within the angular.json and package.json.

Is anybody working on this? Would love to try and make a PR for this. As I understand the issue correct we should lowercase the name within the angular.json and package.json.

@Jefiozie I don't believe so. #17579 (comment) and the following comment cover those details (it's not just calling .toLowercase() 😁 ).

Hi all,

Hello-World is a perfectly valid project name. The problem here is that the schema used by the IDE is not accounting for this.

The above schema also doesn't account for other valid project names such as @foo/bar.

The above doesn't match the actual RegExp used to valid project names

Also there seems to be a misalignment between the library and application schematic, where the library folder is always dasherized, while in the application it's not.

ng g lib fooBar
CREATE projects/foo-bar/README.md (996 bytes)
...

ng g app fooBox
CREATE projects/fooBox/.browserslistrc (853 bytes)
...

Hi @alan-agius4

Thank you for showing us these points of misalignment, I have done some changes already locally to the code and made the same conclusion as you. What would you advise as the best approach for solving this issue?

Personally I never use a - in my names and just use fooBox for my package names and project names. However, if we change this behavior from project name it would (maybe) be a breaking change for the people that use a dash in the project name?

@Jefiozie, project names are valid both in camel case or kebeb case. Therefore we'd need to update the above mention RegeExp.

When it comes to project directories, I am inclined towards always dasherizing the project folder name to align with other schematics where the folder name is always dasherized, that being said It's not a biggy, as long as the schema validation is fixed.

ng g c myCool
CREATE src/app/my-cool/my-cool.component.scss (0 bytes)
CREATE src/app/my-cool/my-cool.component.html (22 bytes)
CREATE src/app/my-cool/my-cool.component.spec.ts (627 bytes)
CREATE src/app/my-cool/my-cool.component.ts (279 bytes)
UPDATE src/app/app.module.ts (474 bytes)

Personally I never use a - in my names and just use fooBox for my package names and project names

This is so also personal preference, I always use kebab casing when it comes to file and directory naming.