feat(core): move generator now includes namespace #770
Conversation
|
Kudos, SonarCloud Quality Gate passed!
|
☁️ Nx Cloud ReportCI is running/has finished running commands for commit f6502f0. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this branch ⌛ The following target is in progress ✅ Successfully ran 6 targets
Sent with 💌 from NxCloud. |
| const destination = joinPathFragments(uniq('app')); | ||
| console.log(tree.read(csProjPath)?.toString()); | ||
| const destination = uniq('app'); | ||
| console.log(tree.read(otherCsProjPath)?.toString()); |
| </Project> | ||
| `, | ||
| ); | ||
| console.log(tree.read(projectFilePath)?.toString()); |
| console.log({ | ||
| originalNamespace: normalizedOptions.currentNamespace, | ||
| newNamespace: normalizedOptions.destinationNamespace, | ||
| }); |
| const newPath = normalizePath( | ||
| relative(directory, options.destinationRoot), | ||
| relative(projectDirectory, options.destinationRoot), | ||
| ); | ||
|
|
||
| console.log({ pathToUpdate, newPath }); |
There was a problem hiding this comment.
I know this one's already here, but let's rm it too
| path, | ||
| contents | ||
| .toString() | ||
| .replaceAll(options.currentNamespace, options.destinationNamespace), |
There was a problem hiding this comment.
It may be worth having more advanced pattern matching here. As is, if your renaming a namespace called Shop and have a variable named something like ShopCreator it would update that variable declaration and may not be desired.
For now, this is likely fine, so don't worry about trying to improve it on this PR, just something to keep in mind.
There was a problem hiding this comment.
Good point, I had my npm scoped deeply nested namespaces in my brain. I agree better pattern matching would be safest.
| currentNamespace: getNamespaceFromSchema( | ||
| tree, | ||
| currentRoot.replace(trimPattern, ''), | ||
| ), |
There was a problem hiding this comment.
This part doesn't work if the namespace has been updated manually or if the project was imported rather than generated. Is there maybe a property inside the csproj we could read for this? There very well may not be, in which case we shouldn't replace things at all.
I'm really kind of wondering about building a basic AST or tokenizer for .NET, that would make things like this easier to query. Just a thought though, wouldn't be super fun...
There was a problem hiding this comment.
Good point.
Renaming the namespaces probably only makes sense in the case the project is using the defaults of the create generators.
- We could conditionally rename based on whether the project name is consistent with what we expect it to be if not overridden or imported?
AFAIK, filename vs namespaces is only a convention.
Also, the csproj has <RootNamespace> which is optional and only serves as a hint to IDEs when creating new class files. * I included it in the rename because it shows up in the vbproj.
The app and lib generators derive the namespace from the project name.
For consistency, it makes sense to align the namespace in the move generator.
Cases:
1 - Update .NET project (.csproj) file name
2 - Update
<RootNamespace>(if exists)3 - Update namespace in all code files within moved project
4 - Update project reference path+filename in all referenced projects
5 - Update namespace in all referencing project code files