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 pull request restructures JavaScript engine dependencies by moving them from the main module into separate optional sub-modules. The main go.mod removes direct dependencies on v8go and Sobek, while new go.mod files are introduced for scripting/v8engine, scripting/sobekengine, and v8browser that declare these dependencies independently. Documentation is expanded to describe the available engine options and usage instructions. The internal/test/wpt module adds a v8engine dependency. This change isolates heavy engine-specific dependencies into optional packages.

Possibly related PRs

• change mentions of goja to sobek #180: Renames Goja to Sobek and adjusts v8engine/sobekengine module paths and package names alongside this restructuring
• Test/updates #166: Refactors tests to be engine-agnostic and removes v8engine-specific test coverage as engines become optional modules
• Fix/remove v8go deps #183: Removes v8go usage and V8-specific code paths from the main codebase, complementing the dependency extraction into separate modules

🚥 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 default/required ones in the gost-dom/browser package.
Description check	✅ Passed	The description clearly explains the motivation and purpose: avoiding heavy v8 engine dependencies by default while allowing consumers to choose their preferred JS engine or none.
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