Skip to content
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

Merged
merged 6 commits into from
Sep 26, 2022

Conversation

tzuge
Copy link
Contributor

@tzuge tzuge commented Sep 8, 2022

Adding msbuild customization files (#469 and #470)

Extending the @nx-dotnet/core:init generator to include initialization of MSBuild customization files Directory.Build.props and Directory.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:

  • Update e2e tests
  • Documentation updates
  • Verify idempotence expectation - Do we need this for the targets file and props file independently or is treating them as a pair sufficient?
  • Remove of the XML manipulation for setting of output paths - What is the backwards compatibility expectation? OutputPath property in projects still needed if Directory.Build.* files are not present (e.g. in workspaces initialized with prior versions.)
  • Code coverage report path - nx workspaces normally output reports to path like coverage/apps/my-app. This potentially can be configured in a property in Directory.Build.props as well
  • CheckNxModuleBoundaries target - this should be possible to handle in Directory.Build.targets

@nx-cloud
Copy link

nx-cloud bot commented Sep 8, 2022

Also, removing use of XML manipulation since it is no longer needed and skipOutputPathManipulation option since it is no longer applicable.
Copy link
Member

@AgentEnder AgentEnder left a 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.

Comment on lines 10 to 12
<Target Name="CheckNxModuleBoundaries" BeforeTargets="Build">
<Exec Command="node $(NodeModulesRelativePath)/<%= checkModuleBoundariesScriptPath %> -p $(NxProjectName)"/>
</Target>
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Comment on lines +100 to +108
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();
});
Copy link
Member

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.

Comment on lines 135 to 147
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,
});
}
Copy link
Member

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, {
Copy link
Contributor Author

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?

Copy link
Member

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

Copy link
Contributor Author

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.

@tzuge
Copy link
Contributor Author

tzuge commented Sep 16, 2022

Hey @AgentEnder, how is the behaviour described by this test implemented?

nx-dotnet e2e › nx g test › should add a reference to the target project

I can't seem to find execution of project-reference generator or addProjectReference on the client from the test generator.

@AgentEnder
Copy link
Member

Hey @AgentEnder, how is the behaviour described by this test implemented?

nx-dotnet e2e › nx g test › should add a reference to the target project

I can't seem to find execution of project-reference generator or addProjectReference on the client from the test generator.

It's found here: https://github.com/nx-dotnet/nx-dotnet/blob/master/packages/core/src/generators/utils/generate-test-project.ts#L81-L90

@AgentEnder AgentEnder marked this pull request as ready for review September 19, 2022 18:01
@AgentEnder AgentEnder marked this pull request as draft September 19, 2022 18:19
@AgentEnder
Copy link
Member

Accidentally converted out of draft when trying to approve checks, going to leave it in draft until you mark it :). Thanks again!

@tzuge tzuge marked this pull request as ready for review September 19, 2022 19:23
@tzuge
Copy link
Contributor Author

tzuge commented Sep 19, 2022

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:

  • I put addProjectReference back in the test generator but no longer subject to skipOutputPathManipulation option, which has been removed.
  • --project-root arg on the check module boundaries feels a bit kludgy; I can't imagine any manual execution of the script using that arg
  • the init generator e2e test is dependent on order of execution of tests since the other generators will run init internally, so it's not guaranteed that the test passes because of the command executed in the test.

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@AgentEnder
Copy link
Member

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!

@AgentEnder AgentEnder merged commit c57fbd3 into nx-dotnet:master Sep 26, 2022
@AgentEnder
Copy link
Member

@all-contributors please add @tzuge for code and design

@allcontributors
Copy link
Contributor

@AgentEnder

I've put up a pull request to add @tzuge! 🎉

github-actions bot pushed a commit that referenced this pull request Oct 5, 2022
# [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
@github-actions
Copy link
Contributor

github-actions bot commented Oct 5, 2022

🎉 This PR is included in version 1.14.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants