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