This LGTM, instead of submodules I'd highly recommend something like git subrepo or similar. It ensures a checkout is a true snapshot w/o having to ensure you initialise the submodules etc…

It also means if you download the source .tar.gz from GitHub it'd include all the dependencies.

Basically git subrepo tracks a folder like a submodule but keeps all it's sources in the main repo.

How this will effect JavaScript performance and features?

@v3ss0n feature wise there was not a ton of ES6 that the version of v8 that was used supported, like @srh said mostly Maps/Sets.

Performance is a tricky one because of the nature of compilers and sorts. I don't think it'll be extremely noticeable unless you're doing massive queries and using JS to iterate each row.

We better do a few benchmarks for popular usecases that use js

The main reason not to put the external dependencies in the source tree is that some of them are huge and would pollute history forever. Are we really going to include a copy of Node.JS inside RethinkDB's repo? (I don't want to put a copy in rethinkdb-vendored either, it'd get its own submodule if anything.) (I want to get rid of the Node.JS dependency: Make a separate repo for web-assets stuff, have the git repo track history of its generated .cc file, include that as a submodule.)

I'd argue using tar balls via a download link is still better than submodules. Submodules are extremely frustrating because you can't just download the sources of a project off Github that uses Submodules.

In my experience they're nearly as fragile as downloaded tarball sources too, but they do have a great added benefit of being able to keep patches includes etc…

Maybe we can use separate repos but still have the build packager clone these git repo's rather than rely on git submodules. That way if you downloaded rethinkdb sources from GitHub you could compile it w/o having to setup the git submodules manually first.

I'd argue using tar balls via a download link is still better than submodules. Submodules are extremely frustrating because you can't just download the sources of a project off Github that uses Submodules.

I also have problem with submodules , they are very fragile and i avoid it in all my repos may it be git or mercurial .

Note that the build system automatically checks out the submodule -- so, I think, you can just ./configure and make like before. So I don't see any inconvenience and don't know how they're more fragile.

However, I don't have a big opinion on this. And I'm not in charge of things. You can make this not use submodules if you want.

@srh as long as it works w/o having to clone from git I think it'll be great, again it's just another source of build issues if you can't compile from a tarball because the build pipeline only works inside a git tree that can checkout submodules.

I agree as a matter of principle that you should be able to build after you rm -rf vendored .git. So a solution which meets those requirements would be a good idea. I think the build process using git clone $path_to_vendored --and-please-checkout-commit abcdef12345 is better than some tarball download and patching because that way we have a repo (or repos) with history as a matter of course, fewer moving parts to maintain.

I dropped submodules, made build process explicitly clone vendored/

JS evaluation in-process would be amazing, don't worry about the user creating bottlenecks, it's just a matter of documenting it, since there is already this risk inside conflict functions for example.

Why would anyone include/download/build the source code of an external package anyways?
Why not require duktape as a dependency? It's a regular library that ships as .so-file + headers.

Anyways, I'd highly appreciate using duktape instead of v8 👍

@jachstet-sea So that the behavior of RethinkDB's query language is defined by the RethinkDB version, not by whatever version your system has installed.

@srh Is this PR still valid? If we resolve the conflicts, can we merge this?

@gabor-boros There is the question of whether we want to merge this.

@srh The question is what this change will cause. If this change will result in fewer build headaches, faster build, smaller binary and does not introduces performance issues I'd be glad to merge this PR.

#6978 was merged into v2.4.x, which adopts QuickJS.