[ASK] Support export

[ad3n]

Is this fork support export keyword?

[tommie]

No.

v8go doesn't support ES modules (it calls ScriptCompiler::Compile, but never ScriptCompiler::CompileModule.)

To elaborate: module support would be great, but it also means having to add an interface to do import resolution. It seems no one has wanted it bad enough yet.

[ad3n]

i have no knowledge on C/C++, i want to help you but i don't know how to start

[stroiman]

i have no knowledge on C/C++, i want to help you but i don't know how to start

It's been a few months. Are you still interested? I have been extending this for my own purpose, adding features of v8 that aren't in v8go, so I'm starting to get the hang of it.

None of my additions are merged to this repo yet, my code isn't properly tested. This isn't a feature I need myself yet (it will come), so it's not a priority for me to implement this particular feature. I'll probably add it eventually if no-one beats me to it. But don't expect this from me for a few months.

But if you want to take a stab at it, I'll gladly help pointing in the right direction. The first step would be to identify which v8 API functionality to use. Apart from the CompileModule function, I would imagine that there's more to it. You probably need to supply some callbacks for resolving imported modules (that's a guess, but a reasonable guess).

I'll also try to give the necessary level of C++ knowledge to work with it. I'm not a hardcore C++ developer, I used it some 20 years ago. But it gives me enough knowledge to work with the code, and understand what is going on.

My own fork is https://github.com/stroiman/v8go (browse the branches, it's not in the main branch. I think it's called external-support).

Also look at my other project, https://github.com/stroiman/go-dom where I use it (branch name specified here). Look at the go.mod file and the two shell scripts for updating. This allows me to use either my own working copy, or the github version under the tommie/v8go name.

It's also worth noticing, setTimeout and setInterval are actually not part of the ES standard. That was little bit of a surprise to me. So you need to supply those functions yourself, if your code depends on them. I'm adding an event loop to my browser, but currently I only have a setTimeout that ignores the timeout value (i.e., schedules for immediate execution). My simple event loop is a gorouting, which reads work-items from a channel (works pretty well so far). But the timing of tasks is not implemented.

[ad3n]

@stroiman Can you give me an example? i don't understand when compare your repo to this repo

[stroiman]

@stroiman Can you give me an example? i don't understand when compare your repo to this repo

First, be sure, you're on the right branch. My changes are in the external-support branch.

Also be aware that we're looking into restructuring the code into multiple files, (look at the PR for this repo). So if you do start making changes, it'd be a good idea to coordinate ;)

Two examples I have added in my repo are:
ObjectTemplate.SetAccessorProperty and ObjectTemplate.SetIndexedHandler. Neither have any PRs as they're not ready to merge to master.

The last requires injecting a Go-callback to C-code. It has been shoehorned into existing FunctionTemplate callback mechanism. I want to simplify how Go-callbacks are handled, as it appears that 5-10 new callback types are needed to fully support the SetHandler functionality of v8. There are two overloads, one for named properties, one for indexed properties, and each have 5-6 optional callbacks (get/set/query/delete, etc)

[stroiman]

See my other note here for a list of features in my fork

#71 (comment)