workspace.members that point to a file are silently ignored

[ehuss]

Problem

When workspace.members includes a path to a file, that member is silently ignored. I think it should at least be a warning, if not an error. This regressed in #8511 where it was changed to ignore files. But I think the intention there was only in the case of globing (such as when members points to a directory, and that directory contains stray files). It wasn't intended to ignore entries in members that pointed directly to a file.

Steps

Create a workspace:

[workspace]
members = [".", "./foo"]
[package]
name = "x"

Create an empty file "foo".
Create src/lib.rs.

Run cargo metadata. Note that it complete ignores "foo".

Possible Solution(s)

I think this should at least be a warning, but should probably be an error.

Notes

No response

Version

cargo 1.95.0-nightly (fe2f314ae 2026-01-30)
release: 1.95.0-nightly
commit-hash: fe2f314aef06e688a9517da1ac0577bb1854d01f
commit-date: 2026-01-30
host: aarch64-apple-darwin
libgit2: 1.9.2 (sys:0.20.3 vendored)
libcurl: 8.7.1 (sys:0.4.83+curl-8.15.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Mac OS 26.2.0 [64-bit]

[ehuss]

With an eye towards possibly supporting workspaces with cargo-script, here are some ideas on how to resolve this:

• Change it now so that members only ignores files if the member matches at least one package.
  • That means it would have the following behavior:
    • members = ["somefile"] -- Error
    • members = ["somedir/*.rs"] -- Error
    • `members = ["somedir/*"] -- Error unless there is at least one valid package. (Today it succeeds if the directory only contains files. It errors if it is empty.)
  • I don't expect this to affect any existing users, since it would be a pretty unusual thing to do, and it is relatively easy to resolve if they did.
  • This would make it easier to transition to a world where members can point to scripts, since versions from now until cargo-script members are stabilized will give a clear error message. Unfortunately versions 1.47 till now will not behave well.
  • It would also resolve an obvious bug.
• When cargo-script supports workspaces, it would (at least at first) be opt-in where the frontmatter needs to specify package.workspace.
  • At this point, we allow workspace.members to point directly to files, essentially removing the above error (assuming the members entry matches at least one valid entry).
    • members = ["somefile"] -- Success iff this is a script.
  • This leaves the problem of globs.
    • I think it would be good if we can support scripts/*.
    • The workspace loader could load any files it finds inside a glob and check if they are scripts and the package.workspace is set correctly. I think this would be the least disruptive option assuming the performance is reasonable.
    • workspace.members could have new syntax to say scripts/* really should load script files (that is, don't ignore files). Or it could a separate field like workspace.script-members.
    • We could introduce the concept of workspace editions, and change the members behavior across an edition (or some other opt-in field). For example, globs could ignore files starting with a . by default, but otherwise assume files are scripts. If users have things like README.md, they'll be required to include them in the exclude list.
    • It could have a hybrid mode where somedir/* has this behavior:
      • If there are directory-based packages, loads those and ignores all files.
      • An explicit somedir/script would include that script.
      • If the directory only contains files, then it assumes all of them are scripts. exclude is required to exclude things like README.md. Files starting with . would also be ignored.
      • This doesn't handle a directory with a mix of scripts and directory-packages well. It's also complicated and hard to explain.

I have an assumption that when we add cargo-script to workspaces that it will set the msrv of the workspace to whichever version where cargo-script workspace members is first introduced (no matter what we do).

[epage]

Change it now so that members only ignores files if the member matches at least one package.

I worry this could end up being surprising. If I put my scripts in my crates/ dir, then they will get ignored and the cause would not be obvious or discoverable.

The workspace loader could load any files it finds inside a glob and check if they are scripts and the package.workspace is set correctly. I think this would be the least disruptive option assuming the performance is reasonable.

A risk is not-quite scripts that would error. Do we skip errors and avoid that or do we report errors assuming that it is a script, just transiently malformed?