rescript-compiler
rescript-compiler copied to clipboard
rescript-lang
Apply `-bs-g` flag via environment variable
As per Discord discussion, to avoid accidental production builds with -bs-g applied via config, apply it via environment variable instead.
Do you use debug build by default?
Currently, I turn it on occasionally, when I need to inspect something at runtime, so not by default.
how about generating .g.js for -bs-g
Doesn't it introduce the same issue that it's required to change sources to switch the build? (e.g. change imports in js files)
I would like this (or something similar) as well. I'm starting a new project and hoping to enable -bs-g by default in the early stages, but eventually we'll need a production output mode and it would be a shame to need bsconfig.json adjustments to toggle it.
How about a command line argument to bsb that turns on the -bs-g compiler flag? That would also allow it to be used on demand or (in my case) added to a "dev build" command.
@TheSpyder Just fyi, flag was the first thing proposed in Discord discussion but @bobzhang preferred env var way back then.
I can still vote for a flag as my preference 😉
An environment var would be fine, though, I'd just set it temporarily e.g. BS_DEBUG=true bsb instead of bsb -debug
I find bs-g very useful and always have it on in my bsconfig.json. I strip it away using sed for production builds.
If this is going to be implemented, I think it would be useful to have an environment variable similar to "DUNE_PROFILE" instead of one that only turns dev mode on.
strip it away using sed for production builds
Exactly. I don't mind how it's implemented, as long as I don't have to patch the config in a build script.
Anything would be better than sed-ing the config for production build. Who is gonna make the decision here? @bobzhang?
I'm reaching the point where I just want a way to specify a completely different bsconfig.json for my production builds
I'm happy to pick up this, do we agreed on it?
Seems like having 2 different bsconfigs it's a pretty common scenario, rather than one env variable that toggles the bs-g. But both are compatible, so, can I just try to create a draft of this?
how about using bsb -dev and pickup bsconfig.dev.json, would it complicate things too much?
@bobzhang that would be awesome!
For bonus points, it would be amazing if bsconfig.dev.json could be a partial config and only overwrite options it specifies (falling back to bsconfig.json. That can be tricky with nested objects, but even a simple shallow overwrite setup would be better than requiring near-complete duplication of bsconfig.json.
IMO that would make it less complicated to understand as well.
@bobzhang that would be awesome!
For bonus points, it would be amazing if
bsconfig.dev.jsoncould be a partial config and only overwrite options it specifies (falling back tobsconfig.json. That can be tricky with nested objects, but even a simple shallow overwrite setup would be better than requiring near-complete duplication ofbsconfig.json.IMO that would make it less complicated to understand as well.
Also would be super amazing to have bsconfig.prod.json and any other bsconfig.ENV.json that uses bsconfig.json as a base config
Also would be super amazing to have
bsconfig.prod.jsonand any otherbsconfig.ENV.jsonthat usesbsconfig.jsonas a base config
For complicated needs, perhaps, but one step at a time. I'd rather see --dev and bsconfig.dev.json now than wait until bob has time to work on a fully configurable solution.
@bobzhang to avoid possible conflicts, I think something like bsb -config dev to pick up bsconfig.dev.json.
except -bs-g, do we have more use cases?
Note -bs-g is a bit different, for this flag, when you turn it on, in general you would like to make it effective in your dependency as well.
This is related to ppx-dev-flags https://github.com/BuckleScript/bucklescript/issues/3761, however, it is slightly different, for dependencies, you don't want it to be triggered
except -bs-g, do we have more use cases?
Different warnings configuration for dev and prod builds.
-- sorry if you get double posts
Different warnings configuration for dev and prod builds.
This is actually not suggested, why do you want that? Note you can turn off some warnings for each file for convenience
This is actually not suggested, why do you want that? Note you can turn off some warnings for each file for convenience
In development, having some warnings as warnings but in production turning them into hard errors. Like if there is a big match and I want to try one branch at runtime w/o implementing/mocking others. I don't like adding annotation in this case b/c it is easy to forget to remove one.
I'm sure I've requested different warnings for dev and prod 🤔 maybe that was just a Discord discussion, sorry for not recording it here. I would very much like to change all of my configured warnings to errors in production builds.
I'm also planning to work on some conditional compilation to remove debug code from production; that will involve using -bs-D to turn debug on in development.
The PPX dev adjustments you mentioned is something I'd like to look into in the future, but have never considered due to the difficulty of toggling command line arguments. For example ppx-expect, which will compile tests written inside production source code for dev, but produce no code for those tests in production (or at least that's how I think it works, I've never really tried it).
@alexfedoseev I think it was suggested in the Discord that OCAMLRUNPARAM can be used to set the warnings on each run of bsb.
Anyway, if we are indeed going for a generalized bsconfig.[ENV].json approach, where the [ENV] could be passed as a command-line bsb option, it would solve a lot of issues.
I have the same use case as @TheSpyder, where I want to vary -bs-D flags somehow. Interpolating env vars in bsconfig.json could be another solution to that particular problem.
@yawaramin Yeah, this is how I address this case currently. But since this issue is being discussed I'd prefer doing everything via configs rather than pretty cryptic OCAMLRUNPARAM.
@TheSpyder -bs-D seems to be a valid use case, I am wondering that -bs-g automatically brinings -bs-D DEBUG in scope, would that cover most of your use cases?
I'm only just getting into the conditional compilation I was talking about back in June, and it looks like -bs-g now sets -bs-D DEBUG? And it has done so for a while, since I'm still on v8.0.3?
This worked perfectly, now I just need a way to control -bs-g without editing bsconfig.json so I can remove it in CI :)
-- sorry if you get double posts
Different warnings configuration for dev and prod builds.
This is actually not suggested, why do you want that? Note you can turn off some warnings for each file for convenience
How would one add an annotation to disable a specific error for a specific file?
The following:
[@bs.config { warnings: { error: "+A-3-44-102-103" } } ]
Produces:
