Let’s put aside the english definition of “mono”, the term monorepo (at least as far as I’ve heard it, and what I believe all participants in this feature request are asking for) is specifically used to describe a repository where multiple packages are developed together for convenience (for example making cross-package changes with a single PR). They usually depend on each other but are treated as independent logical units.
As a TypeScript developer, being forced into a single namespace is extremely annoying. To give you an idea of the sort of monorepo I’m used to, TinyMCE has 6783 TypeScript modules (including tests) spread across 23 packages. I am now working on a moderate sized (400-500 files) ReScript project with 12 logical packages. If we ever try to introduce ReScript to TinyMCE core, monorepo support will be essential.
I do not want to run 12 copies of bsb
, which wouldn’t even work as described by others above who have tried it. I want to use one, as I do in TypeScript. For now I have chosen to develop under a single bsconfig
file, which seems to be what you are encouraging us to do, but it forces me to use namespace hacks. Fully 80% of the files in my project are manually namespaced by package e.g. modules/somepackage/src/Somepackage__ModuleName.re
because namespace: true
is unavailable to these packages and we have to implement it manually. We create the Somepackage.re
file with all of the module aliases inside, and then use it from other packages as Somepackage.ModuleName
. This is confusing and error-prone because nothing actually prevents using the internal modules directly.
This sounds like it would solve most of my problems 
I fully appreciate that it might not be possible to implement all of the features a separate bsconfig
file per package would imply. And that it might take a few releases to get it to the place we’d like it to be (I complain, but I’ve been developing with manual namespaces for over 12 months).
I do want to note however that JS build tools do support monorepos. The monorepo install tool (yarn
in my case) creates symlinks for each source package under node_modules
so cross-package imports work perfectly using the package.json
name and I expect bindings will as well.