More configuration! (entry points, compilers, public etc)

[jaredly]

So we're using the package.json to put config, but what should we put there? There are some issues that I think fall under this:

• Make compilation to js optional + native compilation #17 make js compilation optional, native possible
• [lowpri] separate directories for public vs. private. #3 specify what things are "exported" to clients
• Add ppxFlag support. #12 ppxFlag support

And other things that I'm looking for:

• bucklescript
• specify the path of the built artifact

"rebel": {
  "targets": {
    "./build/my_app.js": {
      "engine": "bucklescript",
      "entry": "./src/js/main.re",
    },
    "./build/my_server.native": {
      // no engine specified, defaults to ocamlc? or sth
      "entry": "./src/server/main.re",
      "extraFlags": " whatever",
    },
  },
},

Rust's cargo is useful to look at

[chenglou]

What's the benefit do specifying the build artifact path btw?

[jaredly]

flexibility? Especially if your target is javascript

[chenglou]

Ok, but we'd still have to overtake that entire folder. Is that ok?

[jaredly]

yeah for bucklescript I guess it's not a single target. So yeah that's totally fine. The "target" key would just be a directory in that case I guess

[vramana]

Slightly tweaking @jaredly's idea. I want to land something similar to the following in #27.

  "targets": {
    // style 1
    "bucklescript": {
      "entries": [ "./src/client.re", "./src/server.re" ] ,
      "flags": "whatever"
    },
   // style 2
    "bucklescript": {
      "entries": {
         "my_client": "./src/client.re", 
         "my_server": "./src/server.re" 
       } ,
      "flags": "whatever"
    },
    // style 3
    "native": {
      // no engine specified, defaults to ocamlc? or sth
     "entry": "./src/main.re",
      "flags": " whatever",
    },

[jaredly]

hmm I think that makes in more confusing. I think splitting it up by "input -> output" makes more sense than splitting it up by engine

[vramana]

@jaredly Can you elaborate on why it's confusing? I am not clearly able to see it.

[vramana]

Oh you want some part of code to be compiled by one compiler and other part by another compiler?

[jaredly]

for example, how do I specify that I want BS to compile two things separately to different destination directories?

[vramana]

@jaredly Everything is flat for now. But in future you can do this with style 2 right:

"entries": {
   "client/index": "./src/client",
   "server/index": "./src/server"
}

[jaredly]

sure. and if you want different flags for the different targets?
it just seems like unifying around the concept of a build target will make the configuration more natural -- yes, you could make it so that the flags argument takes an object with a target as well, but it feels unnaturally split-up that way.

[chenglou]

Can this be an array so that it's not a pain to work with in YoJson?

[vramana]

@jaredly Hmm. Totally valid point. The way rebel is built works right now supporting two different compilers in the same build is either hard or not possible. Same situation with two different compiler configurations. I didn't really think about this till now.

@chenglou Is this what you had in mind?

"targets": [
  {
    "entry": "./src/client",
    "engine": "bucklescript",
    "target": "client/index"
  },
  {
    "entry": "./src/server",
    "engine": "bucklescript"  
    "target": "server/index"
  }
  {
    "entry": "./src/server",
    "engine": "native"  
  }  
]

[jaredly]

@vramana that array configuration looks good to me. Can jenga just kick off 2 separate build processes? Or maybe our rebel cli would do that instead, parsing the json w/ yojson and passing config options to jenga

[bsansouci]

I really don't want to manually list the files that need to be compiled, that would be back to Makefiles from my perspective.

Here are a bunch of use cases that I've personally encountered so far:

• build a simple project, which can be imported as a lib. One target, super simple.
• build a library where you have non-lib code that you also want to bundle (tests, demos). You need 2 targets, and one is the main importable one
• build a project with two different builds (one for server side reason, one for client side reason), either of which can be compiled to a different JS file (webpack would take care of packing for frontend side JS). Those are different codebases (though can have shared reason code), so different entry points.
• build a project with multiple targets (JS, ios, android), where the codebase is mostly the same (eh... hopefully?).

That last proposal might hit all of those use cases.

[vramana]

@bsansouci You never have to list all the files. You only need to specify the entry points and which compiler you want it to compiled by and the rest all will be handled by rebel.

[jordwalke]

Is there any update on a way to add compiler args? It would be nice if there was even a very manual way to add extra args to specific files even (relative to their package root).

• It avoids bikeshedding on the best way to specify conventions for when to add args to certain files. It could just be a dumb list called extraFileCompileArgs in the rebel targets section that says:

"targets": [
  {
    "entry": "./src/client",
    "engine": "bucklescript",
    "target": "client/index",
     "extraFileCompileArgs": [
      {"file": "./src/MyFile.re", "extraArgs": ["-inline", 100]}
     ]
  },
  {
    "entry": "./src/server",
    "engine": "bucklescript"  
    "target": "server/index",
     "extraFileCompileArgs": [
        {"file": "./src/MyFile.re", "extraArgs": ["-inline", 100]}
     ]
  }
  {
    "entry": "./src/server",
    "engine": "native",
     "extraFileCompileArgs": [
      {"file": "./src/MyFile.re", "extraArgs": ["-inline", 100]}
     ]  
  },
    // Or if you want to specify flags regardless of entrypoints,
    // Put stars everywhere else
    {
    "entry": "*",
    "engine": "*",
     "extraFileCompileArgs": [
      {"file": "./src/MyFile.re", "extraArgs": ["-inline", 100]}
     ]  
  },
]

• Note, I just based that off of @vramana's most recent suggestion.
• Even if there ends up being a better way to implement a convention, this very granular ability seems like it could always come in handy for things we haven't yet supported.
• This should be pretty easy to implement, no?

[vramana]

@jordwalke

Yeah I think this should be pretty trivial to implement. In the case where you want to add extraFileCompileArgs regardless of the backend. I think keeping it under rebel.extaFileCompileArgs is better. I planning on something similar but this approach seems better to me. Should we also allow this to pass flags to all files.

"extraFileCompilerArgs": [
  { "file": "*", extraArgs: [ "-inline", 100  ] }
]

[jordwalke]

Yeah, I like the "file":"*" idea.

As far as sticking extraFileCompilerArgs being under the rebel root that would work well too. I'm not highly opinionated on that. I did like how in my suggestion, a property can always be found at a particular "key path/depth", and the value for any field for any file, is the union of all the values at that key path that match the target/file. Kind of like pattern matching where * acts like _.

[jordwalke]

If rebel supports flags, then I will switch the ReSS css layout project to use rebel. I need the flags because I have to pass optimization flags while benchmarking various backends.