@all should not try to build -custom bytecode executables

[nojb]

When defining byte executables purely for the purpose of compiling to JS with -no-check-prims to avoid errors due to primitives which are only present in JS, they cause errors when compiling in -custom which makes @all unusable.

[nojb]

Better still, maybe a dedicated mode for javascript compilation would solve the problem in a neater way.

[ghost]

Indeed, we talked about that with @rgrinberg. The only issue is that we can't remove the target when the js mode is not present without breaking backward compatibility. Although, we could add a field (explicit_js_mode) in the dune-project file to force the use of the js mode, and it would become the default in Dune 2.0.

[rgrinberg]

(using explicit_js_mode 1.0) sounds fine to me. Although I think that for this option to be useful, it would have to be present in the workspace as well. As composing your project with other projects will make the problem resurface.

@nojb do you want to work on this?

[ghost]

We just talk about this with @rgrinberg, putting it in the workspace file might break the build of vendored projects, so it should really only go in the dune-project file. Regarding the syntax, we could use either (using explicit_js_mode 1.0) or (explicit_js_mode), but given that we expect this feature to not change until Dune 2.0 and to disappear with Dune 2.0, it seems simpler to just write (explicit_js_mode). It's basically a property of the vanilla dune language rather than a proper extension.

[nojb]

@nojb do you want to work on this?

I am interested in the feature, but it is not blocking so I don't want to commit myself at the moment due to extremely tight time availability right now.