Update WeslToml.md with more precise algorithm for include/exclude

[stefnotch]

I noticed that the include/exclude section doesn't properly specify what to do in certain edge cases.

1. What to do when there's a nested wesl.toml file
2. If I have root = "./shaders" combined with include = ["foo/bar"], then what should happen? Should I still look at foo/bar, or should it be ignored since it's nonsense

[stefnotch]

This doesn't cover the "implicit wesl.toml" case yet. As in, whenever we see a package.json, we should pretend that there's a wesl.toml next to it.

[mighdoll]

Good question on the nested case. If it's not clear what to do, could defer if it's not needed by any current projects.

another future case to think about. with include/exclude alone, exclude takes priority. if we decide to respect gitignore, is the priority: include < gitignore < exclude?

re: nonsensical mixes of root and include, should we warn?

[stefnotch]

Bevy is going to need the nested case. They'll want a root level wesl.toml (bevy), which then references the wesl.tomls of all the sub-projects (bevy_pbr, bevy_...)

Good question. I'm not yet sure if we want to look at the gitignore at all, since there's the case where I do code generation. Generated wesl code is a prime candidate for .gitignore, but the language server should still look at it.
(Though what the formatter should do is debatable.)

Yeah, warning would be very polite. Even straight up throwing an error might be reasonable.

[mighdoll]

if not gitignore, then probably node_modules in exclude by default (I think you mentioned that elsewhere). Keeps the typical case smooth. Explicit exclude would override that. (Could make that default exclude of node_modules conditional on there being a package.json someday if we want to get fancy, but probably harmless)

[mighdoll]

re: nonsensical root and include, how 'bout warn and drop the root? Seems like a common scenario given our defaults. Users add a version and an include, but don't add a root.

[stefnotch]

We need a root, since import package:: needs to refer to something.

I'd be very happy about an alternative that requires less configuration though.

[mighdoll]

Bevy is going to need the nested case. They'll want a root level wesl.toml (bevy), which then references the wesl.tomls of all the sub-projects (bevy_pbr, bevy_...)

It makes sense that bevy may want to divide their shaders into subsets, but do you have some more detail on what this might look like? I'm looking over at bevy-wgsl and realizing that I don't yet understand what they'd want out of multiple wesl.toml files.

[stefnotch]

It doesn't make too much sense when you look at that repo. It becomes more obvious once you look at Bevy itself, and realize that every "crate" is an independently published project https://github.com/bevyengine/bevy/tree/main/crates

It's possible to only use bevy_render, and supply the rest of the renderer yourself. (I think)

At the same time, they want users that only depend on Bevy to only have import statements like import bevy::...

[stefnotch]

Closing in favour of #182