Standardize line encodings

[Yongbeom-Kim]

Description

Adds a .gitattributes file to standardize all line encoding to CRLF for the following files (LMK if there are any other important files to standardize, or any to omit):

• *.js
• *.ts
• *.tsx
• *.md
• *.cjs
• *.json

Fixes #209
Sequenced after #204 (oops, sorry about that)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

N/A

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[RichDom2185]

Sequenced after #204 (oops, sorry about that)

No worries, looks like there are now merge conflicts due to the squashing. BTW, is there a specific reason we are choosing CRLF and not LF?

[Yongbeom-Kim]

I've fixed the conflicts

From what I can see, there is no particular reason for CRLF, other than the fact that the current eslint rules specify CRLF in particular

[shenyih0ng]

i think there's a typo here:

+ eol=crlf
- eof=crlf

[shenyih0ng]

if we want to take things even further we can introduce a .editorconfig file to ensure new files always have the right line endings

ref (it's a great read): https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/

[leeyi45]

if we want to take things even further we can introduce a .editorconfig file to ensure new files always have the right line endings

ref (it's a great read): https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/

Let us just go forward with adding this. I've been searching for the longest time for some way to get vscode to standardize line endings without having to commit .vscode. Good to see such a solution exists.

[RichDom2185]

Let's recreate this branch directly off the latest master? Seems like we can just directly branch off master and cherry-pick ec37780 (discarding the lockfile while resolving the conflicts) instead of going through the hassle of dealing with all the merge conflicts from the recently-merged PRs.

[martin-henz]

@Yongbeom-Kim what's the status of this PR?

[martin-henz]

@Yongbeom-Kim what's the status of this PR?

[Cloud7050]

@martin-henz to my understanding, @leeyi45 is incorporating these changes into #244. This original PR can probably be closed.

[martin-henz]

@martin-henz to my understanding, @leeyi45 is incorporating these changes into #244. This original PR can probably be closed.

OK