Make JS engines optional dependencies when pulling in gost-dom/browser

[tomlinford]

Right now pulling in gost-dom/browser also adds v8 engine as a dependency, which is pretty heavy. This change lets API consumer pick which JS engine to use, if any.

[coderabbitai]

Walkthrough

This PR extracts JavaScript engine dependencies out of the main module into separate optional sub-modules. The top-level go.mod no longer requires v8go or Sobek; new module manifests were added for scripting/v8engine, scripting/sobekengine, and v8browser (each declaring their engine-specific dependencies). Documentation (README_SCRIPT_ENGINE.md) was expanded with usage and engine options. internal/test/wpt/go.mod adds a dependency on the v8engine module. No public APIs or source logic were changed.

Possibly related PRs

• PR 183: Removes v8go usage and V8-specific code paths from the main codebase, directly related to extracting V8 dependencies.
• PR 203: Moves tests/imports to scripting subpackages and updates v8engine test files, aligning with the new scripting/* module layout.
• PR 222: Introduces and modifies the v8engine and sobekengine packages (names, scopes, and tests), addressing the same engine-module split.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change—making JavaScript engines optional dependencies instead of forcing V8 as a heavy default dependency.
Description check	✅ Passed	The description clearly relates to the changeset by explaining the problem (V8 as heavy dependency) and solution (optional JS engine selection), directly corresponding to the file changes reorganizing dependencies.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

README_SCRIPT_ENGINE.md (1)

114-114: Fix typo in link reference.

The link reference should be [Sobek] not [Sobak] to match the project name.

Proposed fix

-[Sobak]: https://github.com/grafana/sobek
+[Sobek]: https://github.com/grafana/sobek

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Fix trailing space.

Proposed fix

-- `github.com/gost-dom/browser/scripting/sobekengine` - Pure Go JavaScript engine 
+- `github.com/gost-dom/browser/scripting/sobekengine` - Pure Go JavaScript engine

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	- `github.com/gost-dom/browser/scripting/sobekengine` - Pure Go JavaScript engine
	- `github.com/gost-dom/browser/scripting/sobekengine` - Pure Go JavaScript engine

🧰 Tools

🪛 markdownlint-cli2 (0.18.1)

71-71: Trailing spaces
Expected: 0 or 2; Actual: 1

(MD009, no-trailing-spaces)

[stroiman]

Hey.

Thanks for contributing this.

I have been aware of the problem. I ultimately had a different solution in mind: The script engines are moved to their own git repository, i.e. gost-dom/browser/scripting/v8engine -> new git repo gost-dom/v8engine.

However, the interface is still in changing, and kept in internal/ scope for that reason; so the multi-repository approach isn't feasible yet. It is the plan to make it public, allowing 3rd party script engines; if someone fancy testing with SpiderMonkey / JavaScriptCore / QuickJS, whatever.

I was a bit reluctant to this change at first; as I have previously learned of others having bad experiences with nested modules. But it could appear that the complaints were either unjust or just outdated.

I know I had nested modules already; but they were internal tools never intended for user consumption; and I created go.mod files in these exactly for the same reason as this change, to avoid pushing their dependencies to users of this module.

Versioning?

This change turns one go module into 3 go modules; but there's only one build/version script, as well as a single CHANGELOG.

From what I can tell, Go supports tagging version tags for submodules, e.g. scripting/v8engine/v0.x.y; I assume that that submodules follow the same version of the root module when not specified?

Would it make sense to have separate versioning of the submodules?

You mention AWS SDK v2 as an example. How do they handle submodule versioning?

Regarding build scripts

Build/versioning uses JavaScript tools for no other reason than I already knew these tools.

I'd be more than happy to replace those with native Go tools if that makes sense.

[tomlinford]

Hi, I think your long term plan makes sense. Also feel free to just reject this PR if you'd prefer, we're using this change locally and just handled it with a replace directive in go.mod.

Considering how many tags the AWS Go SDK v2 repo has, I have to imagine it's pretty heavily scripted. It looks like there's a root tagged version and then also tags for each of the individual services, and those tags are just the path to the module. It doesn't seem like they try to ensure that the versions are aligned across the different services.

One approach too would be to simplify things a bit and only have the v8 engine as a separate submodule -- pulling in a pure go js engine probably wouldn't be too bad for the typical consumer of the library.

[stroiman]

I'm doing a lot of work in the JS engine at the moment, as I am working on Worker support. I'll merge this into my feature branch, and see if it results in issues.

But an issue was reported on v8go which uses submodules (to solve a different problem). In v8go, vendoring doesn't work. I'm not sure if I understand the diagnosis correctly, but it appears that vendoring doesn't work with submodules.

tommie/v8go#116

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

internal/test/wpt/go.mod (1)

3-3: ⚠️ Potential issue | 🟡 Minor

Align Go version with other modules.

The module uses go 1.25.3, while most other modules use go 1.25. Update this to go 1.25 to maintain consistency across the codebase.

♻️ Duplicate comments (1)

README_SCRIPT_ENGINE.md (1)

71-71: ⚠️ Potential issue | 🟡 Minor

Fix trailing space.

There is a trailing space at the end of line 71.

📝 Proposed fix

-- `github.com/gost-dom/browser/scripting/sobekengine` - Pure Go JavaScript engine 
+- `github.com/gost-dom/browser/scripting/sobekengine` - Pure Go JavaScript engine

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: b9f21c74-cccf-43bb-8931-deb282ddbb51

📥 Commits

Reviewing files that changed from the base of the PR and between c4fdf7b and 1ca32f9.

⛔ Files ignored due to path filters (3)

• go.sum is excluded by !**/*.sum
• go.work is excluded by !**/*.work
• internal/test/wpt/go.work is excluded by !**/*.work

📒 Files selected for processing (6)

• README_SCRIPT_ENGINE.md
• go.mod
• internal/test/wpt/go.mod
• scripting/sobekengine/go.mod
• scripting/v8engine/go.mod
• v8browser/go.mod

💤 Files with no reviewable changes (1)

• go.mod

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check golang.org/x/net versions across all go.mod files

echo "=== golang.org/x/net versions in all go.mod files ==="
fd -e mod -x sh -c 'echo "{}:"; grep "golang.org/x/net" {} || echo "  (not present)"'

Repository: gost-dom/browser

Length of output: 464

---

Align golang.org/x/net versions across modules.

The repository has a version inconsistency for golang.org/x/net: two modules use v0.48.0 (internal/test/wpt/go.mod and internal/code-gen/go.mod), while most others use v0.47.0. Align these versions across the codebase unless the difference is intentional.