-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core): adding templates with default output path properties to init generator #526
feat(core): adding templates with default output path properties to init generator #526
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit b4fed0f. 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 ✅ Successfully ran 9 targets
Sent with 💌 from NxCloud. |
Also, removing use of XML manipulation since it is no longer needed and skipOutputPathManipulation option since it is no longer applicable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is still a draft, but I wanted to leave some preliminary thoughts.
This is looking great so far, and is definitely an excellent first contribution. I really like how it simplifies the handling of these actions.
<Target Name="CheckNxModuleBoundaries" BeforeTargets="Build"> | ||
<Exec Command="node $(NodeModulesRelativePath)/<%= checkModuleBoundariesScriptPath %> -p $(NxProjectName)"/> | ||
</Target> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this would be accurate when dealing with projects that's names don't match the file structure. Since we control the node script too, let's update it to take the project root as a parameter. Then we could look for the project based on its root path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add project-root as a parameter and accept either... https://github.com/nx-dotnet/nx-dotnet/blob/master/packages/core/src/tasks/check-module-boundaries.ts#L90-L95
If project provided use it, if project-root provided look up the project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my understanding of getProjectFileForNxProject
, there should only be one dotnet project under each nx project root. We could overload the project
argument, so if file path value with file extension is provided (csproj, vbproj, etc.), then it looks for the nx project configuration where the root is part of the path. Alternative would be to have a different argument if there's a good name for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to use a different argument, s.t. the original parameter doesn't have any new modality added to it. I'd use --project-root
as the flag, should be added as projectRoot
in the lines I linked above.
it('should not add directory build props and targets files if props file exists', async () => { | ||
appTree.write('Directory.Build.props', ''); | ||
const spy = jest.spyOn(devkit, 'generateFiles'); | ||
await generator(appTree, null, dotnetClient); | ||
|
||
expect(spy).not.toHaveBeenCalled(); | ||
const hasTargetsFile = appTree.isFile('Directory.Build.targets'); | ||
expect(hasTargetsFile).toBeFalsy(); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good for now, in future I'd like to update these operations to add the target if it's not in there already even if file already exists.
if (!initialized && !isDryRun()) { | ||
const checkModuleBoundariesScriptPath = normalize( | ||
relative( | ||
host.root, | ||
resolve('@nx-dotnet/core/src/tasks/check-module-boundaries'), | ||
), | ||
); | ||
|
||
generateFiles(host, path.join(__dirname, 'templates/root'), '.', { | ||
tmpl: '', | ||
checkModuleBoundariesScriptPath, | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't need the isDryRun flag, it is only necessary when the dot net cli is creating files. When we generate files through nx devkit, nx handles dry run for us
@@ -71,10 +70,6 @@ async function addNewDotnetProject( | |||
configuration.targets.test = GetTestExecutorConfig(); | |||
} | |||
addProjectConfiguration(host, projectName, configuration); | |||
await manipulateXmlProjectFile(host, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should init
generator be run as part of import-projects
with the removal of this XML manipulation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, init
should have always been called in here, that's a miss on my earlier part
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I added the call of the init
generator without conditions, so it is run even if no projects are found.
Also, I put
return async () => {
await installTasks()
}
and it's inconsistent with GenerateProject
, but I wasn't sure if the not awaited result there is intentional.
… for msbuild task
Hey @AgentEnder, how is the behaviour described by this test implemented?
I can't seem to find execution of |
It's found here: https://github.com/nx-dotnet/nx-dotnet/blob/master/packages/core/src/generators/utils/generate-test-project.ts#L81-L90 |
Accidentally converted out of draft when trying to approve checks, going to leave it in draft until you mark it :). Thanks again! |
No problem. I think it's good for review at this point. The commit prefixes don't necessarily make sense, but I'm assuming this will get squashed for the proper conventional commit log entry. A few notes:
|
…ject and verify call
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
This looks good to me 🎉, I'm going to spend some time testing the functionality manually and then we can cut a release. Thanks @tzuge for the large contribution, this will put the project in a more maintainable state! |
@all-contributors please add @tzuge for code and design |
I've put up a pull request to add @tzuge! 🎉 |
# [1.14.0](v1.13.4...v1.14.0) (2022-10-05) ### Features * **core:** adding templates with default output path properties to init generator ([#526](#526)) ([c57fbd3](c57fbd3)) Oct 5, 2022, 7:19 PM
🎉 This PR is included in version 1.14.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Adding msbuild customization files (#469 and #470)
Extending the
@nx-dotnet/core:init
generator to include initialization of MSBuild customization filesDirectory.Build.props
andDirectory.Build.targets
. The targets file is a placeholder for workspaces to configure customization that should be imported later. The props file includes build output path properties equivalent to what is currently added per project via XML manipulation.Some remaining work:
coverage/apps/my-app
. This potentially can be configured in a property inDirectory.Build.props
as well