I recently took a huge risk and left Netlify to pursue an opportunity of a lifetime to start a startup. Subs is currently in development. You can r...
For further actions, you may consider blocking this person and/or reporting abuse
Yarn workspaces could save you the common linking step. :)
What you need to add to the root
package.json:Then remove all
node_modulesfolders in the mono-repo, remove thepackage-lock.jsonfile and then runyarnin the root directory.Example with yarn workspaces and lerna
Thanks a lot! I'll give this a try. This is exactly what I am trying to do.
is there anything like this for NPM ?
Came to write exactly this. Workspaces with Lerna can really help organize and manage the monorepo.
Not to rain on your parade but what does Subs offer that Google password management does not? I have already sold my soul to Google and it fills in passwords already connected to my google account in every browser that I use without using a fourth party. What is your use case? What would I gain by switching and how much will it cost? Good luck on your startup (no sarcasm intended)!
What is the benefit of a planned to be gigantic monorepo vs using packages?
It's a Coke and Pepsi argument, both have their pluses and minuses. For me I can add in GitLab CI instructions to build for all the different platforms and make sure everything is good before releasing all at once.
Also so far I've really enjoyed doing one commit that represents a larger body of work. For example, I needed to make a Chrome extension and that doesn't just involve the extension package, it involves, the
clientpackage and theapipackage. So it makes sense to me to have centralized commits that represent the whole idea. It's easier for me to track things.And each of these repos is technically a npm package. I am just not publishing them.
Also running
git push origin masteronce just saves time rather than doing it 8 times. And having one PR/MR is easier to deal with for me. It's a larger PR/MR which is usually bad but in this case it doesn't cause conflicts because it's many separate packages.Also by keeping the
yarn linkinside the repo the setup is easier. Onecloneand a link, and you are good to go. It means I can develop the common library at the same time as the client for example.// , I'm glad to see you want your git commits to tell a cohesive story. It's kind of what the Sand of Sky blog recommends:
sandofsky.com/workflow/git-workflow/
// , I recommend being careful not to optimize too closely. One of the best ways to avoid optimization is the ultimate flexibility: Keeping the option on the table to throw out the code, or well abstracted parts of it, and rewrite that code or product from scratch.
It's a little known "dark" pattern of Software Design, from the shadows of Agile, called "Sacrificial Architecture."
It came to mind when I read this in your post:
Should the prototype usually become the final code?
martinfowler.com/bliki/Sacrificial...
Great content! Thanks for sharing your workflow. I'm about to start a project with Vue targeting web, desktop (Electron) and mobile (NativeScript) so this is comes really in handy.
Secure password management tools are in high demand, tho nowadays it's very challenging venture to go into by actually building them :) Best of luck with Google OAuth and AES256, if you can bring unique features compared to Lastpass, Dashline, Bitwarden, etc and reduce the security risks, all roads are open.
Looks pretty neat. Have you looked into flutter yet? Seems like it can further reduce your codebase.
Instead of
yarn linkwhich I used to use a LOT, look intoyarn workspaces. I have converted to this and it is much more seamless in automatically linking between shared/common packages.