-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
newline format #2558
Comments
Can you explain why such functionality is needed? |
Git thinks that CRLF/LF files are different. LF is the default for linux, and CRLF for windows. If you're generating the files as part of a build on a windows system, where git is set to convert to CRLF on checkout (or the file is CRLF for whatever reason), the file is marked as changed, even if it's not. It's a minor annoyance really. It would make sense if the swagger generation line ending matched the expected line ending type for the operating system the tool was run on, i.e. linux generates LF files, windows generates CRLF. |
We could maybe accept a PR to support this provided that we can pass the new line configurability through to whatever we use to generate the JSON in the first place. For example, System.Text.Json won't support this until .NET 9: dotnet/runtime#84117. |
One can also address the issue using gitattributes |
This looks like it may effect the EOL in the file but is there a solution to also apply to the generated summaries? Our summaries are writing as a string in the json which this gitattribute wont apply to. For example /// Generates a swagger output in yaml as: /api/Account/Login: Ideally we could have the clrf be consistent across Windows and OSX when generating as well. |
I use the command 'dotnet swagger tofile --output ..\clientlib\api.json$(OutputPath)$ (AssemblyName).dll v1' as a post build command in my csproj file.
Currently the generated api.json file has LF as the newline character. Is it possible to make it CRLF?
The text was updated successfully, but these errors were encountered: