Describe how to link in a web project w/o bundling

[mighdoll]

Some js projects want to be able to build w/minimal tooling - essentially running nodejs and javascript/typescript only - no importing of metadata files, no bundler, no additional tools to run during the build.

Describe how to link in a low tooling world, and what if anything won't work as well in this environment (e.g. language server limitations?, missing package versioning metadata?)

Here's a perspective for example from vis.gl:

I think it is fine if your project support both files and strings and you leave the choice to users.

• I would not be using separate files in my projects,
• and I would expect to run into overwhelming bundling issues if I tried to use published libraries that include shaders in separate files (unless they go through a build step before publishing that inlines the shaders into strings).

vis.gl mentioned that they dropped our spiritual predecessor glsify due to its hard dependency on tooling and the ensuing maintenance problems that caused.

[ncthbrt]

Still think a URL driven model could work for loads/imports on web

[mighdoll]

I imagine you bring up URLs because if every import referenced a public URL, a runtime linker library could load packages without other tools. But in a world where wesl packages are in npm, how does also having URL loading help?

[ncthbrt]

My main thought was that a runtime linker could use the urls to load from a cdn or the backend or whatever without additional machinery or tooling. Whereas tying it to a package manager makes this difficult

On Wed, 11 Sep 2024 at 19:34, mighdoll @.***> wrote:

I imagine you bring up URLs because if every import referenced a public URL, a runtime linker library could load packages without other tools. But in a world where wesl packages are in npm, how does also having URL loading help?

— Reply to this email directly, view it on GitHub https://github.com/wgsl-tooling-wg/wesl-spec/issues/22#issuecomment-2344290205, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCJEWKO6HSJX4MZ3MPRS7TZWB5L7AVCNFSM6AAAAABN5ZOYDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBUGI4TAMRQGU . You are receiving this because you commented.Message ID: @.***>

[mighdoll]

My main thought was that a runtime linker could use the urls to load from a cdn or the backend or whatever without additional machinery or tooling. Whereas tying it to a package manager makes this difficult

Yep it adds difficulty, but I think web folks will expect to use npm.

[k2d222]

Still think a URL driven model could work for loads/imports on web

I have mixed opinions about this -- look at Vite for example.

On one hand it supports importing all kinds of files, like CSS or JSON, even images which is both very cool and very useful, But on the other hand the source files become tied to Vite and incompatible with other bundlers.

my first import proposal was going even further, where basically all import path resolutions are implementation-defined. This allows the same kind of super cool stuff that Vite does (and more, see some examples on the proposal)

@mighdoll and @stefnotch made me realize that whatever is not unspecified by the spec, subjects the ecosystem to fragmentation as implementations diverge and grow more complex. Everyone hates the fragmentation of the web ecosystem for example.

So... At this point I am not sure. Maybe standardizing two syntaxes: one with double quotes and where resolution is left unspecified by the spec, and one with normal paths and separators, well-defined by the spec. A published library would not be allowed to use the quoted imports. I think this is a good compromise.

[mighdoll]

opened #23 to discuss urls in import statements.