Inconsistent handling of hidden files

[davireis]

What version of CUE are you using (cue version)?

$ cue version
cue version v0.10.0

go version go1.23.0
      -buildmode exe
       -compiler gc
        -ldflags -s -w -X cuelang.org/go/cmd/cue/cmd.version=v0.10.0
  DefaultGODEBUG asynctimerchan=1,gotypesalias=0,httpservecontentkeepheaders=1,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1
     CGO_ENABLED 1
          GOARCH arm64
            GOOS darwin
         GOARM64 v8.0
             vcs git
    vcs.revision a7c37ee1eeb84546552bcc70aa280ab7c748e9e9
        vcs.time 2024-08-14T21:53:19Z
    vcs.modified false
cue.lang.version v0.10.0

Does this issue reproduce with the latest stable release?

Yes.

What did you do?

echo -e "package p\na: 1" > file.cue
echo -e "package p\nb: 2" > .hidden.cue
echo -e "package p\nc: 3" > .cue

cue export .
{
    "a": 1
}

cue export file.cue .hidden.cue .cue
{
    "c": 3,
    "b": 2,
    "a": 1
}

cue export .cue
cannot determine package name for ".cue"; set it explicitly with ':'
cannot find package ".cue": cannot find module providing package .cue

What did you expect to see?

The first two commands should yield the same result, and the third one should not fail.

What did you see instead?

The first command should yield the same result as the second. That means that explicitly specifying all the files in the same package should lead to the same result as specifying the directory. However, files that start with a dot are ignored if not added explicitly. Besides being surprising due to the fact that the dot files have a package specified, this breaks an interesting idioms of naming cue files after the files they validate, and those are often configs that start with a dot, like .pkgx.yaml.

Also, for the file named .cue the command fails to infer its package, even though it works just fine if specified together with other files.

[mvdan]

The reason that cue export . and cue export file.cue .hidden.cue .cue are not equivalent is explained in cue help inputs:

Directory and file names that begin with "." or "_" are ignored, unless explicitly listed as inputs.

This was borrowed from Go, as a way to "hide" source files in package directories. This has been in place for a number of years now, so changing that would be a significant breaking change.

.cue is a bit of an odd case, again following the logic in cue help inputs. When using cue export .cue, we don't parse that argument as a CUE file, given that it doesn't have a valid extension - or rather, the name before the extension is empty. Hence we treat it as a package path.

This is different with cue export file.cue .hidden.cue .cue because, once any of the arguments looks like a CUE file, then the rest of the arguments are CUE files too. Note that this is based on what the strings look like, and not what files are actually on disk; otherwise e.g. cue export foo.com/[email protected] could do something extremely confusing if such a file existed on disk.

But what I would instead ask is - what is the use case behind a CUE file named .cue? I have personally never seen that before, and explicitly adding support for it seems a bit odd.