I can’t emphasize this enough! Same can be said for emphasizing on syntax instead of semantics. (We have slightly better syntax - at cost of splitting the ecosystem and a worse developer experience for a long time - but we still have a Js.String2 module).
1 Like
On the first run of
yarn bsb -clean-world -make-world, I got an error because of an incorrect bsconfig.json in one of the dependencies. It seems that previous versions did not check for this? After fixing the dependency’s bsconfig.json, I was able to continue.
Yes, I added a sanity check, glad it profited immediately
bsb: error: build.ninja:15: expected ‘=’, got identifier
Seems I checked in the source changes, but did not prebuild the binary properly on your platform, should be an easy fix
The error message said
%@string is redundant hereinstead of@bs.string is redundant here
It should be @string. We will introduce some more robust mechanism to avoid warn-error in dependencies
1 Like
If you want to pin a transitive dependency, maybe just introduce a field in bsconfig.json?
"pinned-dependencies" : [
]
I do see the error in the editor(amazing), but the compile succeeds
The error diagnostics were never reliable, that’s why we work on capture the warnings in the rebuild, the benefit will trickle down in the editor in the future.
@Hongbo did you manage to reproduce?
I see you renamed my monorepo issue to pinned deps without explanation of what it is… please note that i cant guess what pinned deps are 
@Hongbo yes, this is what I was suggesting in a previous comment:
I am not sure I understand if transitive and direct dependencies should be treated differently. Both could be defined in the top level package bsconfig.json, right?
By the way, there is a related feature in Yarn called “resolutions”, it might be worth to check the documentation and original RFC. It is maybe too complex for the purposes of pinned dependencies, but it might serve as inspiration.
@BlueHotDog the pinned packages solution was explained briefly here. The idea is to solve the monorepo issues by telling bsb which packages are being used “from source”, so:
- installation of these packages is skipped
- changes are always picked up
Thanks @jchavarri!
I’ll add a link to the Issue, as i think the issues should be ReScript source of truth and not the forum.
But it’s great to see such a detailed explanation.
And yes. if the whole point of the community rift is to align better with JS(and provide better DX), IMO yarn resolutions is a much better solution(which we already use extensively in our projects, and works, so i’m not sure there’s even an issue) vs adding another field people will need to learn(plus document, maintain etc etc etc)
1 Like
I understand that there are some duplications between bsconfig.json and package.json. The reason is that we don’t want to be tied to a specific package manager, in the future, it may make room for our own package manager
@Hongbo, using the file format isnt the same as being tied to yarn/npm(e.g there are even already 3 package managers on top of package.json)… i just think that if the priority is DX (as it should be IMO) -> forcing duplication for some ambiguous reason isnt a good idea IMO.
The pinned package support is finished https://github.com/rescript-lang/rescript-compiler/pull/4826, will make a release for testing!
3 Likes
How will pinned dependencies work in monorepo?
Currently i’ve a resolution flag in the root package.json.
Now i’ll need to copy that to all the various bsconfigs i’ve? what happens if i dont?
Could it be possible to also have a regex-like syntax there? so we can do:
“@orgname/**, !@orgname/comes-from-package-manager”
this should be pretty easy to add once we have a solid implementation