Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd like to discuss feasibility of adding a default .gitattributes file that enforces a more consistent behavior with EOL=LF including the scenario of checking out the project. I haven't fully tested this, so please share your experience. To share any consequences and observe the expected impact on existing projects, I suggest making the same change to the file in a project root, which is already here (unlike many other projects) but lacks
eol=lf
.If there is some reason against using
.gitattributes
in most Nuxt projects, it'll be beneficial to at least provide this information to the developers who would otherwise try to configure it on their own.Git context
Git provides a global configuration of
core.autocrlf
, which is by default "false" if not defined, but in Windows installer it's pre-selected as true by default. Value of "false" means no processing on line endings, "true" means checking in as LF and checking out according to system (CRLF on Windows and LF on Unix) [StackOverflow]. (Other related configuration iscore.safecrlf
.)In practice this means that with a value of "true", developers may experience their project being checked out as CRLF, which will naturally conflict with prettier and they'll have to reformat everything. This increases the learning curve of any onboarding, and especially they are new to Nuxt, this means they'll first have to extensively research the theory behind EOL, Git, and also prettier along with its lintfix script before they can even safely make a first commit.
.gitattributes values
Using
text=auto
is supposed to make a detection of supported text files automatic, so that any binary files (like .jpg, .png) are excluded from the conversion of line endings to LF, otherwise there can be file corruptions (which have been reported). The alternative would be to explicitly list the extensions of all source files, which is another viable solution where create-nuxt-app could maintain an extensive list of usual types used by any front-end developers; but we'd have to specify whether the "default type" will be binary or text.https://stackoverflow.com/questions/29435156/what-will-text-auto-eol-lf-in-gitattributes-do
The suggested
* text=auto eol=lf
value requires Git 2.10+ to function correctly.The choice of enforcing LF by default for all Vue-related source files is supposed to be opinionated and thus agreed upon by Nuxt to keep it sane, yet anyone will be free to remove the file from their repository.
I assume that this configuration will make it easier to remove workarounds where we replace
\r\n
by\n
in code, for example like:create-nuxt-app/packages/create-nuxt-app/test/index.test.js
Line 15 in de45005
which may include files like shell/batch scripts that are run by Docker, etc.