Open ExplodingDragon opened 2 weeks ago
We need to avoid to introduce more CGO modules.
We need to avoid to introduce more CGO modules.
@lunny Yes, in fact, this pull request is just for functionality verification and will not be merged. Merging it would result in an increase of 10 MB or more in the compiled files.
I'm of the opinion that shipping a full JS engine in go is not worth it, especially because none of them are full-featured. There ought to be better solutions like calling out to a node
binary or using a external API that executes the JS.
I'm of the opinion that shipping a full JS engine in go is not worth it, especially because none of them are full-featured. There ought to be better solutions like calling out to a
node
binary or using a external API that executes the JS.
@silverwind Gitea now supports markup
, but it is not available for AsciiDoc (which supports include::
and is widely used). Maybe we can modify the markup
and pass a token that has read access to the current repository when executing tasks, external tools can use the Gitea API to read the content of includes.
I don't understand much of this topic, but if you are proposing to run JavaScript in the go thread, I would deny that. Running a JavaScript renderer in the browser is of course an option, but keep note that many parts of Gitea expect backend-side rendering so it won't be so simple.
quickjs-go allows executing JavaScript code in Golang, and asciidoctor.js can work in quickjs. We can try to add support for AsciiDoc in the project.
I will submit a pull request to test this feature. This issue is for archival purposes.
Note: This is just a feature validation, not a feature request. AsciiDoc is not a necessary feature for Gitea, We should also not support any tools in Gitea that accept user input for arbitrary code execution.