cmd/cue: fmt should not attempt to resolve imports

[cueckoo]

trafficstars

Originally opened by @myitcv in https://github.com/cuelang/cue/issues/728

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

$ cue version
cue version +fdccfbc5 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

A variation on #653

exec cue fmt x.cue
rm a/a.cue
exec cue fmt x.cue

-- a/a.cue --
package a
-- cue.mod/module.cue --
module: "mod.com"
-- x.cue --
package x

import "mod.com/a"

x: 5

What did you expect to see?

No error

What did you see instead?

> exec cue fmt x.cue
> rm a/a.cue
> exec cue fmt x.cue
[stderr]
import failed: build constraints exclude all CUE files in mod.com/a (ignored: x.cue):
    ./x.cue:3:8

[jpluscplusm]

This "bug" makes working with heavily-nested/-complex CUE hierarchies very painful, in editors where cue fmt is (normally acceptably) invoked on file save. Even when the imports /do/ exist, cue fmt's desire to walk/resolve the imports means that developing files inside such a hierarchy can become extremely painful.

[myitcv]

Actually this issue (rather than https://github.com/cue-lang/cue/issues/1938) is the one which we should address with some urgency because it interacts badly with modules.

cc @mvdan

[mvdan]

One way would be to tweak the way cue fmt calls load.Instances so that any package import errors are ignored. Arguably we should do that no matter what.

I reckon a perhaps simpler workaround in the near term would be to support a "file mode" in cue fmt (https://github.com/cue-lang/cue/issues/1731), because on the Go side I run gofmt -w . much more often than I do e.g. go fmt ./..., and in such a mode we wouldn't use cue/load at all as we would simply walk directories and find files with the CUE extension.

For now, we could enable this mode when all the arguments are CUE files, e.g. cue fmt x.cue or cue fmt *.cue. Later on, i would also want some mode where I can tell cue fmt to walk an entire directory tree, akin to gofmt -w . such as cue fmt files: ., but we can think about that in #1731.