Project directory with .snyk in path name leads to parsing error

[Larusso]

If you have a project located on disk in a path that contains the string .snyk then the policy parser will fail to load/check a policy file.

The reason can be found in this code:

policy/lib/index.js

Lines 84 to 92 in dbda056

	if (root.indexOf('.snyk') === -1) {
	root = path.resolve(root, '.snyk');
	}
	filename = root;
	}
	if (filename.indexOf('.snyk') === -1) {
	filename = path.resolve(filename, '.snyk');
	}

This logic only checks if the path contains .snyk not that the path should end with .snyk.
The function assumes since .snyk is in the path that it is a valid path to a .snyk file.

This issue also breaks other commands like test and monitor which internally call this logic.
We found this during unit tests for our ci system because it generates directories based on internal package names.
One such package is called foo.bar.snyk. You get the idea.

• Command run: snyk policy

Expected behaviour

Loads the empty policy

Actual behaviour

Fails to load the policy

Steps to reproduce

1. create a directory for a project (can be empty) which contains .snyk mkdir -p ~/test/my.snykProject/project
2. create an empty .snyk file in the project. touch ~/test/my.snykProject/project/.snyk
3. change into project directory cd ~/test/my.snykProject/project
4. run snyk snyk policy -d

[Larusso]

One additional note. I think the logic should also check if the calcualated path actually points to a file not to a directory before attempting to open it. In snyk test the command fails with EISDIR
The general error handler at snyk/src/lib/unexpected-error.ts:28:5 is eating up a lot of information what was read etc. It took me a better part of 4 hours to nail down the reason why our example failed only during our internal test runs.