Problem parsing .yarnrc

[mobitum]

Do you want to request a feature or report a bug?

Seems like bug in parsing .yarnrc file in project folder.
I'm using yarn 1.3.2 on Windows.

What is the current behavior?
I created .yarnrc file with single line:
--install.modules-folder "./resources"
I'm getting following error on simple 'yarn' command:
"error An unexpected error occurred: "Unknown token: { line: 1, col: 0, type: 'INVALID', value: undefined } 1:0 in C:\VS...."
I tried even empty .yarnrc with the same result.
My package.json looks like this:
{
"name": "intranet",
"version": "1.0.0",
"license": "UNLICENSED",
"devDependencies": {},
"dependencies": {
"angular": "^1.6.6",
"angular-material": "^1.1.5"
}
}

If the current behavior is a bug, please provide the steps to reproduce.

Just put empty .yarnrc file in your project directory and run yarn command

What is the expected behavior?
.yarnrc should be parsed against available options

Please mention your node.js, yarn and operating system version.
Yarn version:
1.3.2

Node version:
8.9.1

Platform:
win32 x64

[BYK]

@mobitum we need the actual .yarnrc file to be able to investigate. Copy/pasting it in the issue also wouldn't work since it would remove any special characters in it. You may upload it to a Gist directly or to another file sharing service and share the link with us. I work on Windows and I have custom .yarnrc files and I have no issues. We also have Windows tests running for each PR on AppVeyor so it is very likely that your system or that specific lockfile has an issue.

[BYK]

Also, providing the full error, including the path and your project path would be useful since failing with a .yarnrc error in a package that doesn't have a lockfile implies that you have another lockfile laying around, maybe in your home folder.

[mobitum]

This is test I performed - created empty .yarnrc file from my Power Shell console:

PS C:\VS\INTRANET\Intranet\Intranet\Intranet> yarn
yarn install v1.3.2
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.10s.
PS C:\VS\INTRANET\Intranet\Intranet\Intranet> echo '' > .yarnrc
PS C:\VS\INTRANET\Intranet\Intranet\Intranet> yarn
yarn install v1.3.2
error An unexpected error occurred: "Unknown token: { line: 1, col: 0, type: 'INVALID', value: undefined } 1:0 in C:\VS\INTRANET\Intranet\Intranet\Intranet\.yarnrc".
info If you think this is a bug, please open a bug report with the information provided in "C:\VS\INTRANET\Intranet\Intranet\Intranet\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\VS\INTRANET\Intranet\Intranet\Intranet>

Here are .yarnrc and yarn-error.log files from my PC:
linked zip file on my dropbox

[DavidNorena]

any luck ? I'm facing the same problem :(

[rally25rs]

I've noticed before that an empty .yarnrc causes an error. However, the original issue doesn't seem to cause a problem for me:

~/Projects/yarn-test : echo '--install.modules-folder "./resources"' > .yarnrc

~/Projects/yarn-test : cat .yarnrc
--install.modules-folder "./resources"

~/Projects/yarn-test : yarn install
yarn install v1.3.2
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 1.36s.

~/Projects/yarn-test : ls
index.js     package.json resources    yarn.lock

resources/ dir is created as expected.

---

edit:

Just a suggestion if you plan on actually using that line in yarnrc; --install.modules-folder will only apply to the yarn install command, but other commands may not use it (and still look for node_modules instead). It may be better to use --*.modules-folder which would apply it to all commands.

[mobitum]

No luck with that even latest Yarn version:
PS C:\VS\INTRANET\Intranet\Intranet\Intranet> dir .\web\resources
Directory: C:\VS\INTRANET\Intranet\Intranet\Intranet\web\resources

Mode LastWriteTime Length Name

---

d----- 08.11.2017 15:34 angular
d----- 08.11.2017 16:02 angular-animate
d----- 08.11.2017 16:02 angular-aria
d----- 11.12.2017 15:10 angular-chosen
d----- 08.11.2017 15:37 angular-material
d----- 07.12.2017 18:32 angular-material-data-table
d----- 28.03.2018 11:09 angular-material-datetimepicker
d----- 08.11.2017 16:02 angular-messages
d----- 20.12.2017 10:45 angular-moment
d----- 13.11.2017 05:49 angular-resource
d----- 13.11.2017 05:35 angular-sanitize
d----- 16.11.2017 22:29 angular-translate
d----- 13.11.2017 05:37 angular-ui-router
d----- 28.03.2018 11:09 angular-ui-tree
d----- 04.12.2017 12:55 angular-visjs
d----- 04.12.2017 12:57 emitter-component
d----- 09.11.2017 08:25 fontawesome
d----- 04.12.2017 12:57 hammerjs
d----- 13.11.2017 05:51 jquery
d----- 13.11.2017 05:53 jquery-ui
d----- 04.12.2017 12:57 keycharm
d----- 23.11.2017 17:01 material-design-icons
d----- 20.12.2017 10:45 moment
d----- 16.11.2017 22:32 oclazyload
d----- 04.12.2017 12:57 propagating-hammerjs
d----- 07.12.2017 16:46 smart-table
d----- 13.12.2017 18:02 vis
-a---- 28.03.2018 11:10 8235076 .yarn-integrity

PS C:\VS\INTRANET\Intranet\Intranet\Intranet> cat ..yarnrc
--install.modules-folder "./web/resources"
PS C:\VS\INTRANET\Intranet\Intranet\Intranet> yarn install
yarn install v1.5.1
error An unexpected error occurred: "Unknown token: { line: 1, col: 0, type: 'INVALID', value: undefined } 1:0 in C:\VS\INTRANET\Intranet\Intranet\Intranet\.yarnrc".
info If you think this is a bug, please open a bug report with the information provided in "C:\VS\INTRANET\Intranet\Intranet\Intranet\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

[rally25rs]

Might be an issue with windows CRLF line endings?

[bertho-zero]

A .yarnrc file starting with a # completely blocks yarn, even before the log of the command with the version.

EDIT: I use yarn v1.6.0

[mathieuroche]

I had the same problem. I solved it by change the encoding of the file.
The encoding was "UTF16-BE" and not "ANSI".
I suppose the parser only support ANSI encoding.
When I use ">" in Powershell, the file encoding is "UTF16-BE" on my Windows 8.1.
Hope this helps.

[mudcovered]

Seeing this on BSD (but bizarrely only for one user).
In this case /work/netbsd/.config/yarn is a directory created when yarn installed node-gyp. If I remove this directory the error goes away.
On another user account on the same system yarn is perfectly happy with .config/yarn being a directory.
This is with yarn 1.22.4.
SyntaxError: Unknown token: { line: 1, col: 0, type: 'INVALID', value: undefined } 1:0 in /work/netbsd/.config/yarn
at Parser.unexpected (/usr/pkg/libexec/yarn/lib/cli.js:64332:11)
at Parser.parse (/usr/pkg/libexec/yarn/lib/cli.js:64463:14)
at parse (/usr/pkg/libexec/yarn/lib/cli.js:64537:21)
at module.exports.exports.default (/usr/pkg/libexec/yarn/lib/cli.js:64099:96)
at loadRcFile (/usr/pkg/libexec/yarn/lib/cli.js:56942:58)
at /usr/pkg/libexec/yarn/lib/cli.js:56916:14
at /usr/pkg/libexec/yarn/lib/cli.js:101331:14
at Array.map ()
at parseRcPaths (/usr/pkg/libexec/yarn/lib/cli.js:101329:78)
at Object.findRc (/usr/pkg/libexec/yarn/lib/cli.js:101343:10)

[madpilot78]

I'm seeing the same @mudcovered is seeing on FreeBSD with version 1.22.4 installed from FreeBSD ports collection.

Every time I launch yarn I get:

> yarn upgrade
SyntaxError: Unknown token: { line: 1, col: 0, type: 'INVALID', value: undefined } 1:0 in /home/mad/.config/yarn
    at Parser.unexpected (/usr/local/lib/node_modules/yarn/lib/cli.js:64332:11)
    at Parser.parse (/usr/local/lib/node_modules/yarn/lib/cli.js:64463:14)
    at parse (/usr/local/lib/node_modules/yarn/lib/cli.js:64537:21)
    at module.exports.exports.default (/usr/local/lib/node_modules/yarn/lib/cli.js:64099:96)
    at loadRcFile (/usr/local/lib/node_modules/yarn/lib/cli.js:56942:58)
    at /usr/local/lib/node_modules/yarn/lib/cli.js:56916:14
    at /usr/local/lib/node_modules/yarn/lib/cli.js:101331:14
    at Array.map (<anonymous>)
    at parseRcPaths (/usr/local/lib/node_modules/yarn/lib/cli.js:101329:78)
    at Object.findRc (/usr/local/lib/node_modules/yarn/lib/cli.js:101343:10)

/home/mad/.config/yarn is a directory, I tried removing it and yarn works fine, until I try again to install global package, then it recreates the directory to add global configuration there and fails again with the same error. This was not happening with 1.22.0, I'm going to try downgrading to see if I can "fix" it.

[madpilot78]

And having a look at the sources the commit 2cb2fc4 could be the one introducing the regression.

That's what corresponds to line at parse (/usr/local/lib/node_modules/yarn/lib/cli.js:64537:21) above.

[madpilot78]

And having a look at the sources the commit 2cb2fc4 could be the one introducing the regression.

That's what corresponds to line at parse (/usr/local/lib/node_modules/yarn/lib/cli.js:64537:21) above.

I confirm that manually reverting commit 2cb2fc4 in cli.js in the distribution makes this issue go away. But that commit was created to fix another issue, so I'm not filing a pull request. Someone knowing the code better should take a look.

@arcanis as the author of the commit are you willing to have a look at this?

[mike-pumford]

Figured out what is going on with this problem on my system:
`

fs.readFileSync('src').toString()
Uncaught Error: EISDIR: illegal operation on a directory, read
at Object.readSync (fs.js:577:3)
at tryReadSync (fs.js:353:20)
at Object.readFileSync (fs.js:390:19) {
errno: -21,
syscall: 'read',
code: 'EISDIR'
}

This is on one account whicch has its home directory on NFS. And the other failing account on the same system which has the home directory on a native BSD FFS filesystem:fs.readFileSync('src').toString()
'\x1D��\x02\f\x00\x04\x01.\x00\x00\x00\x00��\x02\f\x00\x04\x02..\x00\x00�\x1C\x19\x00�\x01\x04\bpkgdebug\x00\x00\x00\x001.2\x00pn\x00\x00R��\x02�\x01\b\n' +
'forktest.c\x00\x00S��\x02�\x01\b\x05ftest\x00\x00\x00�ғ\x02�\x01\x04\x05build\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
`
NOTE the read succeeds. This is a quirk of BSD but isn't new so I don't think the code should be relying on readFileSync failing with EISDIR on a directory. Even the Linux man page doesn't guarantee that open will always fail on a directory with ESIDR.

So I think there are 2 issues here.

1. Why is yarn attempting to open .config/yarn as a config file when its a directory.
2. It should actually check the path in question is not a directory before doing the read!

According POSIX:
[EISDIR]
[XSI] [Option Start] The fildes argument refers to a directory and the implementation does not allow the directory to be read using read() or pread(). The readdir() function should be used instead.
So that explicitly blesses the BSD implementation allow a directory to be read as if it is a file with read()

Is this similar enough to this issue to be tracked here or should I open this as a new issue?

[paul-soporan]

Closing as fixed in v2 where we only read .yarnrc.yml files that don't have such issues.

https://yarnpkg.com/getting-started/migration