Skip to content
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

Fix: make lockfile parser tolerant to CRLF #4495

Merged
merged 5 commits into from
Sep 19, 2017
Merged

Fix: make lockfile parser tolerant to CRLF #4495

merged 5 commits into from
Sep 19, 2017

Conversation

BYK
Copy link
Member

@BYK BYK commented Sep 18, 2017

Summary

Lockfile parser fails when the lockfile had Windows-style line
endings with an "Invalid token" error. This is default on Windows
and, say when editing the file using vim, it is not obvious or
trivial that the file endings are in Windows-style. This patch
makes the parser tolareate potential "\r" chars before "\n" while
keeping the existing parsing logic the same.

Test plan

Added three new unit tests.

**Summary**

Lockfile parser fails when the lockfile had Windows-style line
endings with an "Invalid token" error. This is default on Windows
and, say when editing the file using vim, it is not obvious or
trivial that the file endings are in Windows-style. This patch
makes the parser tolareate potential "\r" chars before "\n" while
keeping the existing parsing logic the same.

**Test plan**

Added two new unit tests.
@@ -155,7 +159,7 @@ function* tokenise(input: string): Iterator<Token> {
}

col += chop;
lastNewline = input[0] === '\n';
lastNewline = input[0] === '\n' || input[1] === '\n';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does input[0] matter when input[1] === '\n'?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I can change this to input[0] === '\n' || (input[0] === '\r' && input[1] === '\n') to be precise?

Copy link
Member

@bestander bestander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, one nit

@buildsize
Copy link

buildsize bot commented Sep 18, 2017

This change will increase the build size from 9.69 MB to 9.7 MB, an increase of 2.09 KB (0%)

File name Previous Size New Size Change
yarn-[version].noarch.rpm 835.16 KB 835.29 KB 137 bytes (0%)
yarn-[version].js 3.69 MB 3.7 MB 696 bytes (0%)
yarn-legacy-[version].js 3.74 MB 3.75 MB 971 bytes (0%)
yarn-v[version].tar.gz 839.19 KB 839.43 KB 238 bytes (0%)
yarn_[version]all.deb 635.25 KB 635.34 KB 100 bytes (0%)

@BYK BYK merged commit e52e8b1 into master Sep 19, 2017
@BYK BYK deleted the newlines branch September 19, 2017 09:18
joaolucasl pushed a commit to joaolucasl/yarn that referenced this pull request Oct 27, 2017
**Summary**

Lockfile parser fails when the lockfile had Windows-style line
endings with an "Invalid token" error. This is default on Windows
and, say when editing the file using vim, it is not obvious or
trivial that the file endings are in Windows-style. This patch
makes the parser tolareate potential "\r" chars before "\n" while
keeping the existing parsing logic the same.

**Test plan**

Added three new unit tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants