Nswag: Should support specify line endings

Created on 8 Jan 2018  路  9Comments  路  Source: RicoSuter/NSwag

We are using windows OS, the default line ending is CRLF, while the NSwagger generated file is using LF. Some git client will auto change the LF to CRLF and create unnecessary changes.

It will be great if you can provide a parameter which allows user to specify line endings to Windows or Unix style.

image

help wanted enhancement

Most helpful comment

@kspdrgn Interesting solution! Our issue is that line feeds cause problems with Git. So we told Git to ignore the line endings by basically stating that you should ignore this file and leave it LF's since we can't control it.

We did this by placing a .gitattributes file into the project folders that had auto-generated NSwag clients and set the files that Nswag kept regenerating as leaving .LF's to not keep fighting our CRLF vs LF global git setting which normalizes everything for us but then kept causing these files to show up as changed, even though the only thing that changed was the line feeds.

###############################################################################
# Set default behavior to automatically normalize line endings.
###############################################################################
# 11/3/2019 - MRO: Since NSwag perpetually generates clients with .LF's, force it to leave it as is so that our
# autocrlf=true setting in global Git doesn't keep counting this is a file that will be changed.
ApiClient.Contracts.cs text eol=lf
ApiClient.cs text eol=lf

All 9 comments

Second this, we are having the same problem with multiple users on Windows

if it helps anyone, here's my overengineered workaround for converting line endings to CRLF after NSwag generation

using MSBuild to run Powershell to convert the line endings

https://gist.github.com/kspdrgn/4eb48ece8abcefabacd818a95b699648

Our team need this, too. Perhaps the generator should use Environment.NewLine to generate new lines, like so, they will be generated as CRLF on Windows and as LF on Linux and Mac OSX.

@kspdrgn Interesting solution! Our issue is that line feeds cause problems with Git. So we told Git to ignore the line endings by basically stating that you should ignore this file and leave it LF's since we can't control it.

We did this by placing a .gitattributes file into the project folders that had auto-generated NSwag clients and set the files that Nswag kept regenerating as leaving .LF's to not keep fighting our CRLF vs LF global git setting which normalizes everything for us but then kept causing these files to show up as changed, even though the only thing that changed was the line feeds.

###############################################################################
# Set default behavior to automatically normalize line endings.
###############################################################################
# 11/3/2019 - MRO: Since NSwag perpetually generates clients with .LF's, force it to leave it as is so that our
# autocrlf=true setting in global Git doesn't keep counting this is a file that will be changed.
ApiClient.Contracts.cs text eol=lf
ApiClient.cs text eol=lf

@RicoSuter Please do not just use Environment.NewLine as that would perpetualy cause problems with Git as well. I think the best solution would allow the nswag.json file to control what type of line feeds to use so that it is LF's or CRLF's with an optional third setting called "Auto" which then would use Environment.NewLine.

Proposed Nswag.json format:

NewLineBehavior=(possible values are LF, CRLF, Auto)

We've also come across this issue. Our current workaround is to modify the .gitattributes file we include in every repository to include the following:

swagger.cs text eol=lf

This forces all generated files with the filename swagger.cs to use LF endings during checkout, which fixes the issue locally. It does mean we have to use swagger.cs as the filename for all generated files, but as we put them all in their own subfolder anyway it's not too much of an issue.

That being said I would much rather have the suggestion of a NewLineBehavior posted by @xantari so please do consider it as a priority.

I am auto-generating the client as part of the CI/CD process. I too kept running into issues with line endings. This one baffled me for good amount of time:

  1. core.autocrlf is set to true
  2. Client file is generated
  3. File is committed (and LF converts to CRLF)
  4. Client file is generated again
  5. Run git status to see that the file is modified (CRLF is again LF)
  6. Stage the file
  7. Run git status and see that there is no longer a modified or staged file. It just vanished.

Why? Because git is automatically converting LF back to CRLF, so there are no longer any changes!

This wouldn't be unique to nswag, but man was I confused.

Do we really need a new config/option or would it be enough to use convert to/use Environment.NewLine?

I don't think Environment.NewLine would be enough to fix it, cause it's dependent on how they have Git setup. So this necessitates a new field. A few posts up I suggested this as a fix:

Proposed Nswag.json format:

NewLineBehavior=(possible values are LF, CRLF, Auto). Where Auto is Environment.NewLine and would be the default.

Was this page helpful?
0 / 5 - 0 ratings