Some feedback

[saschatimme]

I converted a mediumish (around 5k loc) to bsb-native yested and it was quite smooth! My 360 unit tests now need 1200 ms in js, 400ms with bytecode and 50ms with native 💯.

Here are a couple of things I think could be improved:

• The default flags to bsc seem different. Especially I got warning 40 which was quite annoying. I added ["-no-alias-deps", "-color", "always", "-w", "-40+6+7+27+32..39+44+45"] and everything was fine again.
• It seems that only the first entry in entries will be build.
• Is there a command line argument to bsb to specify which kind, .i.e. js, bytecode or native, will be build? Currently it seems that if there is an entry present in entries this will determine the kind. So if I want to build normally for js and only sometimes for native, I have to comment things in/out in the bsconfig.
• Currently your platform specific dependencies have to be separate packages. Separate packages make it quite hard to iterate fast on things. To lessen the pain I ended up with some npm link magic to have everything still in the same repo. (I can elaborate if you are curious about the details). I think a better solution would be to have the possibility to set on a per directory basis which kinds are allowed.
  This would also reduce the amount of restructuring necessary for a dual build and eliminate the need to extract some sort of interface (like in your ReasonGl thing).

[bsansouci]

Hey @saschatimme, thanks for taking the time to write this
Just to have some real stats, how long does your project take to compile (to js, bytecode, native)?

1. Oh that's a bug, it shouldn't be. I'll work on that.
2. Yeah, that's an undocumented thing. I didn't spend time on allowing multiple entries to build at the same time because I'm not sure of the best way to do it. I'm not sure that building all entires is any useful, I feel like you use js or byte code for dev and then js or native for release. I'd love to hear your thoughts on what you'd prefer
3. Nope you guessed right. Do you think you'd like bsb -make-world -bytecode / bsb -make-world -native
4. Very good point, thanks for bringing it up. I agree that it's too painful right now. Another issue too is that you can go down the route of having functors, but that doesn't work for JS (for JS bsb will build every file, whereas for bytecode/native we use bsdep to determine what's used / not used and only build those). Directory level control would definitely be easier. I'm wondering if we could make it even easier... I might wait until namespaces are in bsb (so probably next release) to implement anything, because that'll greatly influence how we'll make this work.

[saschatimme]

Timings for bsb -clean-world -make-world (as a npm script):
JS: 3361ms
Bytecode: 5099ms
Native: 7319ms

Yeah, that's an undocumented thing. I didn't spend time on allowing multiple entries to build at the same time because I'm not sure of the best way to do it. I'm not sure that building all entires is any useful, I feel like you use js or byte code for dev and then js or native for release. I'd love to hear your thoughts on what you'd prefer

My workflow is currently js for dev and possibly native for release (since Jest for js is just awesome).
Maybe a possibility would be to specify the entry via cli? Combined with

Nope you guessed right. Do you think you'd like bsb -make-world -bytecode / bsb -make-world -native

I think you would be more flexible than now.

And I think waiting for namespaces is the right choice.

[bsansouci]

Just to follow up. number 2 and 3 have been fixed in master.
You can build to a specific target using -backend [js | bytecode | native]. We build all entries that match the target. We only allow building to 1 target, if you need to build to more than one you can run the commands sequentially. If that's an issue please tell me because I'm assuming it won't really be at the moment.

I will check number 1 today and number 4 is related to @TheSpyder 's feedback in #3. I'm still thinking about it but it might be that I allow you to specific specific dirs for specific targets.
I'd like to mitigate the complexity of setting things up. I might enforce a directory name like js is js-only code etc... That would force people to:

1. be consistent (there is no overhead to reading a new codebase because it's the same everywhere)
2. "fast" to setup because there's no config needed, you just create your folder
3. I can pretty easily extend it to allow you to rename those in the config if it becomes annoying. It'd just be a default name.

[TheSpyder]

Sounds reasonable. I'd suggest allowing the rename up front, defaults are great but everyone has their own opinions about project structure. For example at my workplace we tend to group folders by code type, so right now I have

src
  \- demo
    \- html
    \- js
  \- main
    \- re
      \- <source code>
  \- test
    \- doc
      \- <test input files>
    \-re
      \- <test source code>

src/test/re is 100% native, src/main/re is 99% pure reason and 1% JS specific (segregated into a folder).

[bsansouci]

All of this is fixed in master :)