Revise Packaging.md - #173
Conversation
|
no time or interest to finish this, but it's already an improvement to the exitsing file. OK to merge? |
mighdoll
left a comment
There was a problem hiding this comment.
It'll be good to get this in! sorry for forgetting about it and glad you're pushing it forward. lmk if you want help on any of the minor edits, I can make more specific text proposals if needed.
|
|
||
| (TODO: unification with param const?) | ||
|
|
||
| If two packages in the dependency tree are [semver-compatible](https://semver.org/), npm or Cargo will likely unify them, meaning it will include only one version of the package in its output (often the highest semver-compatible version available). |
There was a problem hiding this comment.
I think we might say that users are doing this unification. i.e. users of npm and cargo may unify them.
There was a problem hiding this comment.
Oh, I see, the point is that package managers will sometimes unify by default. I think that's the default for npm, though the rules are overridable and expectations vary on whether indirect dependencies are unified. (AFAIR by default pnpm doesn't unify indirect dependencies, but npm might still do that)
There was a problem hiding this comment.
lemme know if the current revision clarifies.
apply revisions
mighdoll
left a comment
There was a problem hiding this comment.
Looks good, nice work moving this forward! Suggestions below are mostly editorial.
|
|
||
| ## Creating and publishing shader packages | ||
|
|
||
| Any [`wesl.toml`] file declares a new shader package, which can be published using the linker's CLI. |
There was a problem hiding this comment.
in js, wesl-packager is currently a separate cli (from the wesl-link cli).
@mighdoll comment revisions
experimentslee
left a comment
There was a problem hiding this comment.
looking good. best not promise to wesl.toml deps for wesl-js.
resolve/review the 4 comments and then LGTM w/o further review
| 1. The name is sanitized to remove certain common symbols that are invalid in WGSL identifiers (see following section). | ||
| 2. The name can be overriden in the dependencies list in [`wesl.toml`], e.g. `wgsl_name = { package = "@published/name" }`. | ||
|
|
||
| If after these operations, the shader name is still not a valid WGSL identifier, the package will not be reachable from user code. |
There was a problem hiding this comment.
I wonder if it should be an error instead. i.e. the linker must check that the package name is a valid WGSL ident. Does -js do that? @mighdoll
There was a problem hiding this comment.
The packager tool should error and it doesn't. Good one. (the -js library consumer would fail because it's unreachable. The consumer could workaround with a package.json rename, but that's a bit late)
It's time to un-draft Packaging.md