Pinned packages support

[BlueHotDog]

https://github.com/BlueHotDog/reason_monorepo

Monorepo support via common tooling(specifically in the above repo Lerna) is broken.
Monorepo support for JS projects is usually being done by using symlinks to support cross-project dependencies - That's the most basic and common workflow.
Another possible monorepo approach is by using Yarn workspaces, which utilizes symlinking even more by hoisting all dependencies to the "root".

Currently, bucklescript is unable to handle any kind of monorepo setup, which, after trying to bang my head, is impossible to solve and leads to a very weird workflow for any ambitious, project(e.g a modern SPA + Nodejs server in Reason).

The example project above illustrates all the problems, but just to summarize what i've encountered:

• Bucklescript randomly spits "duplicate dependency" warning, when two packages depend on the same package. e.g: package A depends on ReFetch(v1 for example) and package B depends on ReFetch too(same version), and package B depends on package A - will result in this warning, which is incorrect.
• Bucklescript will randomly spit an error that bsconfig.json is broken(it's not) when trying to compile package B.
• Bucklescript will randomly spit a: incorrect assumption about interface(same case as the first scenario)
• Watch is just broken completely for the above reasons
• When compiling to Es6 even more errors happen(paths etc) :(

Links to previous discussions that died out and might be related:
#3521
#4047

As there's no roadmap for reasonml. any type of communication regarding stale issue would really help.

[jchavarri]

Another issue that makes the monorepo experience challenging is #4084. An example use case that we've seen is the generation of .ml and .mli files from .atd files. Because there are BuckleScript libraries in the monorepo that depend on .atd files, and on have dependents as well, we have to run atdgen "off-bsb" with Dune, but this means that bsb doesn't know anything about how these targets are generated, so one has to run scripts for every change to the source .atd files.

[TheSpyder]

Other references to monorepo requests, so we can centralise the discussion
#1950
#2750
#3528

[TheSpyder]

I have forked the monorepo @BlueHotDog posted and rewritten it to show the style of monorepo I would like to use. I've written up all the things this is designed to achieve, and why it doesn't currently work, in the readme:
https://github.com/TheSpyder/reason_monorepo

This structure holds a lot of potential, I very nearly used it for my production project, but the watch-rebuild process is just slow enough to be annoying and the lack of compiler warnings really killed it for us.

[BlueHotDog]

@TheSpyder that's awesome! thank you(hopefully BS gods will hear this)
One requirement that you didnt list which is needed for me is the ability to run each project separately:
i'm developing a chrome extension + front-end and need to be able to run bsb+webpack + etc from two different packages side by side.

The way i'm doing it now, e.g by having a single top level bs-config makes this impossible(you have to run a single build, so when working on the flow i've to:

• work on the extension. close it.
• open the front-end. and vice-versa
  )
  If BuckleScript emphasis is performance, i would argue this isnt performant way to write code :)

[TheSpyder]

@BlueHotDog you can still run each project separately if you want, even in my example 😁

Little-known fact about npm module resolution, it also supports searching for a parent package.json and node_modules folder. This is what makes yarn workspaces work so well.

reason_monorepo spyder$ yarn
<stuff here>
reason_monorepo spyder$ yarn build
<build output>
reason_monorepo spyder$ cd packages/a
a spyder$ bsb
[18/18] Building src/FetchedDogPictures/FetchedDogPictures-A.cmj

packages/b also works, but that's where I have the warning-as-error configured.

In fact, my setup might work for you today if you never use a top-level bsb.

[harigopal]

I actually work on a monorepo that uses Lerna + Yarn workspaces - Pupilfirst.

It's not a traditional workspaces-based monorepo, in that there is a top-level application, with other packages inside it; they're not all side-by-side like in the example @TheSpyder created.

And it works... most of the time.

Occasionally, the bsb compilation will start failing, complaining about the presence of duplicate .re files (files with the same name). At that point, one of the packages (app/javascript/packages/pf-icon) will have a lib/ocaml folder inside it that contains dupes of some Reason files. Deleting that folder gets the compilation going again... until seemingly at random, the lib/ocaml folder shows up again.

It's a bit annoying, but it happens rarely enough that it doesn't get in the way of work, and it was the only way I could set this up as a monorepo.

I haven't a clue why this happens - I haven't been able to replicate it reliably, but it probably has something to do with all packages (including root) having their own bsconfig.json files - and two of the packages depend on another -pf-icon... and it's always pf-icon that gets the weird lib/ocaml folder with the dupe files inside it.

[TheSpyder]

@harigopal your top-level bsconfig.json also loads all the packages as source, which is the technique I ended up using in production, unfortunately that means the packages can't leverage namespace: true.

My guess about your lib/ocaml problem is the language server occasionally realises there is another bsconfig.json and compiles that folder.

[BlueHotDog]

Seems that on BS 8 the situation is better and now i can work with Yarn Workspaces.(was this fixed? couldnt see anything in any communications nor was it on the roadmap.. but.. yeah)

[TheSpyder]

I'm not sure what changed, but I don't believe it has been fixed. I'm still struggling along without access to namespace:true.

If you don't want to keep this open, I'll open a new one 🤔

[BlueHotDog]

Yup, my mistake, wasn't fixed.
@bobzhang is this still planned for the next releases as documented in the roadmap?

[BlueHotDog]

@bobzhang any update on this? is this planning to be getting some attention? unfortunately if this is a no-go i can't use Reasonml and need to move code back to typescript i would just love to know before i make any drastic changes.

[bobzhang]

Hi, sorry for your bad experience. It’s on our roadmap for this half so we will have a look . But I am not sure if we can deliver it in a timely manner to match your expectation. Danni Friedland <notifications@github.com>于2020年8月10日 周一下午9:55写道：

@bobzhang <https://github.com/bobzhang> any update on this? is this planning to be getting some attention? unfortunately if this is a no-go i can't use Reasonml and need to move code back to typescript i would just love to know before i make any drastic changes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFWMK5MDLJJJQ2FO35UJRLR7735XANCNFSM4M4ORL5A> .

-- Regards -- Hongbo Zhang