This came up in the slack channel:
https://kubernetes.slack.com/archives/C0155NSPJSZ/p1651968001107699

There are cases where users would like non-KRM files to be available to functions.

Examples that have come up include:

• including code files, such as Starlark functions or Rego in Gatekeeper ConstraintTemplates: include-file function #2350
• generating or updating documentation markdown
• inputs for generating ConfigMaps, as kustomize does (e.g, env files)
• other generator inputs: Special behavior for generators #2528
• kustomize-style strategic merge patches

I'm sure there are more.

I imagine we could do this with KRM wrappers and SDK library functions to unwrap/wrap the files, so they could be included in the ResourceList.

Where we can identify common file types, it would be useful to give them dedicated KRM types rather than generic File kinds.

I'd be open to more radical changes to the ResourceList, but that would require a KEP to kustomize (https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli).

Speaking of which, with kustomize moving towards KRM functions, how is it planning to deal with this? Mounting filesystems and/or pulling files over the network is maybe necessary in some cases (e.g., helm charts), but seems suboptimal for common cases.