A simple app or library would have a wesl.toml that looks something like this:
[package]
edition = "2026_pre"
I'd be nice to make the [package] part unnecessary. That'd be one less thing to learn for the simple case.
We can simplify things for users by putting the package keys at the root of the toml. bun chose this approach for their toml config, see: bunfig.toml. Like us, bun expects their config to be a semi-optional adjunct to the required native config (package.json, cargo.toml).
I tried a PR for wesl-rs that parses the wesl.toml and makes the [package] optional. In that rev, the package keys work both at the root of toml or under [package]. So we could support it both ways if we'd like.
A simple app or library would have a wesl.toml that looks something like this:
I'd be nice to make the
[package]part unnecessary. That'd be one less thing to learn for the simple case.We can simplify things for users by putting the package keys at the root of the toml. bun chose this approach for their toml config, see: bunfig.toml. Like us, bun expects their config to be a semi-optional adjunct to the required native config (package.json, cargo.toml).
I tried a PR for wesl-rs that parses the wesl.toml and makes the
[package]optional. In that rev, the package keys work both at the root of toml or under[package]. So we could support it both ways if we'd like.