✅ Deploy Preview for blazorstatic ready!

Name	Link
🔨 Latest commit	f9580ae
🔍 Latest deploy log	https://app.netlify.com/sites/blazorstatic/deploys/670ad23352bda60008c430e1
😎 Deploy Preview	https://deploy-preview-38--blazorstatic.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Nice, thank you for the effort.

I am okay with the JSON format. It is important to keep it consistent across IDEs and among developers. We should probably include a .editorconfig file with specifications for JSON. I made a new issue for it.

I made some changes to ensure that the content/blog folder remains in the templated project.

I haven't found a solution to delete the content/blog folder but keep the .keepFolder file (which itself prevents an empty folder from being excluded; see placeholderFilename). So, I configured it to exclude .md files and the media folder.

It's becoming clear to me that we need to separate the dotnet new template from the GitHub "Use template" functionality. For example, there's the .keepFolder file that serves no purpose in the GitHub template, and there's no easy way to exclude it during the GitHub "Use template" creation. On the other hand, maintaining a separate project for this is additional overhead. Any thoughts on this? It is nice to have the template to serve in both ways.

When we add more parameters, we should think about how to keep them well-documented. A simple README is fine for now, but it will become unnecessary maintenance if it can be handled automatically (how is the question..).

Also, commands like exclude-default-posts should be kept "public" so multiple templates can share them. This way, we won't have to duplicate code for each new template. I'm not sure if this is possible though.

This raises a lot of questions, which might not be critical right now, but we should have at least a vision for the solution.

Some thoughts regarding:

• .editorconfig: Definitely a good idea. Very easy to just grab an existing one from a large OSS project you like.
• .folderKeep: So that was one thing I spent a lot of time playing with but wasn't sure what the expected outcome was based on the issue, but I think it makes sense this way that the folder is created with no posts/media.
• GitHub templates: I'm not sure how much value they provide versus just offering .NET templates since the vast majority of C# developers are most likely going to just dotnet new rather than use GitHub, but I understand the value of having it for getting an end-to-end project setup. Definitely need to consider separating them, and it might make sense to just make the GitHub template an artifact of the .NET template by just running a job that creates a new empty project with the GitHub actions etc already checked in.
• Documentation: I definitely think this is an area that could be improved on the project as I myself still had to play around with it before I kind of understood some stuff. I think it would be beneficial to maybe start simple with a tutorial of sorts?

I think it's worth studying the WebAPI template structure to get an idea of how you might want to proceed. It would be really neat to have the ability to have things like MudBlazor or FluentUI templates as well to make it even easier for C# developers to start creating sites.

I think the work here technically would close this ticket but we could maybe take some of the ideas from this discussion to create more issues.

I will close this. I agree with you on most of the parts.

• .editorconfig => I will educate myself on the topic and resolve that, shouldn't be complicated
• .folderKeep => is there to keep the empty folder, guiding users to put there md files there.
• templates => yeah, the BlazorStaticMinimalBlog will be read-only, probably generated by dotnet new command from a pipeline that will run once there is a new version of the package. The template itself will have its own repo or will be under BlazorStatic/Templates repo..
• docs => I was talking specifically about the docs for the various parameters for the dotnet new template. But you are right, our docs is falling behind. we actually have an issue already Documentation really needs an update #33 .