bs-typed-css
bs-typed-css copied to clipboard
glennsl
Monorepo setup
Related conversation: https://github.com/glennsl/bs-typed-glamor/issues/4#issuecomment-395306523
To answer some of your points:
No start script despite the readme saying there is. lerna run start also doesn't seem to work properly.
The readme says you have to cd into one of the packages and run yarn start. Nevertheless, it usually comes down to the preferred development flow (e.g. do you work with all packages together or just on one of the packages, etc). So this can be changed of course.
Can't consume packages directly from github, they have to be published to npm
What do you mean? If you're referring to the "inter dependencies" (bs-typed-glamor requires bs-typed-css-core), then that's what lerna does, it creates symlinks.
lerna publish rather than np. Not sure how they compare yet, but I really like np
I never used np, but from what I can see lerna publish does something very similar.
The readme says you have to cd into one of the packages and run yarn start
Right, I should probably try reading ;)
do you work with all packages together or just on one of the packages
At this stage it's really all packages. Or rather just glamor and core, but react is defunct and should probably be removed. So if it's possible to have a workflow that allows working on both with one watch command, that would be great.
If you're referring to the "inter dependencies" (bs-typed-glamor requires bs-typed-css-core), then that's what lerna does, it creates symlinks.
No, I mean consumer in third-party projects. Right now you just reference the github repo, but that's not possible with a monorepo I think. With this I have to publish to npm for third-parties to be able to use it. I think that's one of the major differences. At this stage there is/will be a lot of experimentation, which in some ways break the expectations you have when consuming published packages IMO.
I never used np, but from what I can see lerna publish does something very similar. Alright, cool. I'll just have to try it out I guess.
Another concern I have is how yarn deals with linking (like npm link), which seems to me to be poorly. Perhaps I don't understand how it works, but linked packages seem to just be ignored, which is annoying.
Additionally the refmting of the Reason code really isn't good, and creates a lot of noise. Could you revert that?
Hmm, is there a way to “disable” rfmt?
but react is defunct and should probably be removed
I’ll remove the package then
So if it's possible to have a workflow that allows working on both with one watch command, that would be great.
Alright, I’ll see what I can do
No, I mean consumer in third-party projects. Right now you just reference the github repo, but that's not possible with a monorepo I think. With this I have to publish to npm for third-parties to be able to use it. I think that's one of the major differences. At this stage there is/will be a lot of experimentation, which in some ways break the expectations you have when consuming published packages IMO.
I don’t see this much of a problem, to publish packages to npm. I would avoid actually requiring deps directly from GitHub.
And if you don’t want to publish with a specific version yet, there are different options: tag dist releases as next or as rc or even alpha/beta. That’s much better, easier to consume and it clearly sets the expectations.
Perhaps I don't understand how it works, but linked packages seem to just be ignored, which is annoying.
What do you mean by “ignored”?
is there a way to “disable” rfmt?
In vscode? Probably a setting. It shouldn't be enabled by default though, it's never been for me. These kind of things should be per-project settings.
I’ll see what I can do
Great. Don't spend too much time on that though. It'd be really nice, but certainly isn't necessary. I mostly asked because you seemed to already know it was possible somehow.
I don’t see this much of a problem, to publish packages to npm.
It's yet another thing I have to keep track of and manage. Certainly not the end of the world, but I don't think it's insignificant. Less is more and so on.
And if you don’t want to publish with a specific version yet, there are different options: tag dist releases as next or as rc or even alpha/beta. That’s much better, easier to consume and it clearly sets the expectations.
I'm not familiar with tags, but surely you'll still have to have a version number that must be bumped each time you publish? It would do better at setting expectations though
What do you mean by “ignored”?
i mean it ignores and installs over linked packages. So every time you add/remove/change a dependency, you have to relink all linked packages
Alright, I addressed the comments.
You can now build and start the packages from the root folder:
-
yarn build
-
yarn start
When you do a release, you run yarn release, then you get prompted to select a version
In our case, the initial version is 0.1.0-beta.0, so if I select prerelease I get told that the new version will be 0.1.0-beta.1.
Then lerna will take care of updating the version in each package
If that's ok with you, I suggest to publish the first version 0.1.0-beta.0, so that you also get a feeling how it works.
NOTE: the first time you publish it, you need to select "Custom" and enter the same version 0.1.0-beta.0 again, otherwise lerna will bump it. From there then always select one of the other choices.
Let me know if you need anything else, thanks!
Awesome, thank you! I'll have to play around with this a bit, but looks pretty great!
Could you revert the formatting of the test files too though? Other than that I think it should be ready to merge, as soon as I've checked that everything works well.
Yeah, I guess for starters is good enough. I'm happy to help if something can/should be improved. Just let me know 😇
Could you revert the formatting of the test files too though?
Oh yeah sorry, forgot about that.
Btw, the bs.js files are git-ignored. If you prefer to, I can add them back in.