Open emahuni opened 2 years ago
Thanks!
Would you be interested in making a documentation PR?
On Thu, Sep 1, 2022 at 11:15 AM Emmanuel Mahuni @.***> wrote:
🤓 Compliment and suggestion for documentation
I was thinking and looking for exactly this. It removes a lot of mental overhead. Workspaces concept is fine, but then I wanted to make sure packages I add into a monorepo remain usable elsewhere and are not coupled with the monorepo. I thought exactly of this; why not commit the repos refs and manage them separate from the monorepo, that's how I searched and found this.
However, the idea that you ditch Yarn workspaces is fine for other projects, but I am using it this way: I am managing yarn dependencies through workspaces and then decouple them by the default .gitignore that meta imposes. There are a lot of advantages from doing this. The main is how Yarn manages references to dependences in a monorepo. I neither want to publish some of these packages as they are private, nor want to cement them into the monorepo as they will be used in other monorepos. This way, I have both of both worlds. I can work with monorepo commands from yarn and manage them as separate repos that can be installed and worked with separate from each other.
So the suggestion is that this needs to be mentioned in the documentation, that the metarepo can be used this way.
Furthermore, meta-yarn and meta-npm need to use yarn as is... such that any new commands or other commands that yarn offer are not interpreted by the plugin. Eg, I may want to use newer Yarn 3 commands and they won't work with the old meta-yarn plugin. I guess this is for the meta-yarn repo, but I just wanted to mention that here.
Again thanks for this great idea.
— Reply to this email directly, view it on GitHub https://github.com/mateodelnorte/meta/issues/305, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHOX6Q2WGPYQWNVSUPJLDV4DJCTANCNFSM6AAAAAAQCQMMAQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Furthermore, meta-yarn and meta-npm need to use yarn as is... such that any new commands or other commands that yarn offer are not interpreted by the plugin. Eg, I may want to use newer Yarn 3 commands and they won't work with the old meta-yarn plugin. I guess this is for the meta-yarn repo, but I just wanted to mention that here.
@emahuni keep in mind you can always just use meta exec "yarn3 stuff"
🤓 Compliment and suggestion for documentation
I was thinking and looking for exactly this. It removes a lot of mental overhead. Workspaces concept is fine, but then I wanted to make sure packages I add into a monorepo remain usable elsewhere and are not coupled with the monorepo. I thought exactly of this; why not commit the repos refs and manage them separate from the monorepo, that's how I searched and found this.
However, the idea that you ditch Yarn workspaces is fine for other projects, but I am using it this way: I am managing yarn dependencies through workspaces and then decouple them by the default .gitignore that meta imposes. There are a lot of advantages from doing this. The main is how Yarn manages references to dependences in a monorepo. I neither want to publish some of these packages as they are private, nor want to cement them into the monorepo as they will be used in other monorepos. This way, I have both of both worlds. I can work with monorepo commands from yarn and manage them as separate repos that can be installed and worked with separate from each other.
So the suggestion is that this needs to be mentioned in the documentation, that the metarepo can be used this way.
Furthermore, meta-yarn and meta-npm need to use yarn as is... such that any new commands or other commands that yarn offer are not interpreted by the plugin. Eg, I may want to use newer Yarn 3 commands and they won't work with the old meta-yarn plugin. I guess this is for the meta-yarn repo, but I just wanted to mention that here.
Again thanks for this great idea.