Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Consider reworking arguments to file()

See original GitHub issue

I’m always having trouble remembering what checks exactly are performed for the different parameters to file(). For example, does exists = false check whether the file does not exist and fail otherwise? (No, it does not.) While that’s part of the documentation, I believe this could be made more clear by renaming parameters. How about:

exists -> verifyExists
fileOkay -> canBeFile
folderOkay -> canBeDir
writable -> mustBeWritable
readable -> mustBeReadable

Issue Analytics

State:
Created 4 years ago
Comments:13 (13 by maintainers)

Top GitHub Comments

1reaction

ajaltcommented, Feb 11, 2020

I decided on a solution that isn’t perfect, but that I’m okay with:

I added the canBeSymlink parameter to a new overload and deprecated the existing version as discussed. In addition, I added another overload with no parameters that isn’t deprecated. This way calls with no arguments (e.g. file()) aren’t marked as deprecated.

Calls with unnamed arguments (e.g. file(true, false)) will still always be marked as deprecated, but I doubt that pattern is common. People can always remove the deprecation by adding names to the arguments.

1reaction

sschuberthcommented, Jan 30, 2020

There are actually two kinds of native “symlinks” on Windows: Junctions (for directories only; since Windows 2000) and “real” symbolic links (since Windows Vista). Both of these should be detected by my code snippet. The best tool I know to create / handle these on Windows is the Link Shell Extension.