feat: Make `@sveltejs/sv-utils` browser-friendly

[x0k]

I would like to reuse the same logic based on @sveltejs/sv-utils both in the implementation of an addon and in factories that generate files for sandbox environments directly in the browser.

Currently, this is not possible because the Node.js version of the yaml dependency is bundled. As a result, the generated bundle contains the following import:

import { createRequire } from "node:module";

Would it be possible to use a browser-compatible version/build of yaml instead, so that @sveltejs/sv-utils can also be used in browser environments?

[sacrosanctic]

There's probably other functions that can only run the a node env.

edit: the current package has support for browsers, but we build for the node env.

https://npmx.dev/package-code/yaml/v/2.9.0/package.json

[sacrosanctic]

I don't think its reasonable to add this restriction to the CLI. A workaround is to run your own CI to build a custom version that supports the browser.

[x0k]

There are probably other functions that can only run in a Node environment.
Run your own CI to build a custom version that supports the browser.

I have already done this, and in my case there are no issues with the other functions, since I only use the transformation APIs.

I don't think it's reasonable to add this restriction to the CLI.

A separate submodule could be added that exports environment-agnostic/browser-compatible functions.

[sacrosanctic]

It seems pretty niche for something you already have a solution for. What is the upside to include it as a part of this repo?

[x0k]

This is not a solution, but rather a workaround.

The submodule approach would only make sense if there is a need for a clear separation between the APIs.

I have already described my use case. Whether it is niche or not, it exists. If the package can also be used in the browser, there may be more use cases like this in the future. The question, in my opinion, is whether supporting browser usage is a goal or a non-goal for this package.

[jycouet]

I would say that it's not an absolute goal, but if it's not too hard, I'm all for it. Do you know any yaml option for it ? So that we can look at it ?

(note that it's not a priority atm)

[sacrosanctic]

https://npmx.dev/package-code/yaml/v/2.9.0/package.json#L23-L40

the current one has support for browsers. It just that we only bundle the node version.

[x0k]

I only added aliasFields to the build config so that the browser field is considered during the build.

		inputOptions: {
			resolve: {
				aliasFields: [['browser']]
			}
		},

However, this could result in browser primitives being included in the final bundle (this needs to be checked).

In the 3.0.0-0 release, the distinction between versions has been removed, but there is no stable release yet.

[sacrosanctic]

In the 3.0.0-0 release, the distinction between versions has been removed, but there is no stable release yet.

Then we can just wait for the stable release and bump it.