Melos Monorepo of packages + Bitbucket + OnePub for Private Distribution

[ObserverMoment]

Hello,

I am looking for some examples and / or guidance on how to achieve the following setup.

We want to:

1. Host private dart and flutter packages for members of the team to access in our various apps. These packages need to be versioned with all previous versions also accessible.
2. Use melos + monorepo (hosted on bitbucket) to manage versioning / changelogs etc of our packages.
3. Publish (private) to OnePub via CI/DC when commits are merged into our main branch.

Is there any documentation or guidance on how this might be achieved?

Thanks,

Rich

[bsutton]

Richard, thanks for reaching out. Answers in line. 1. Host private dart and flutter packages for members of the team to access in our various apps. These packages need to be versioned with all previous versions also accessible. This is precisely what onepub does. This article goes over the details of publishing: https://onepub.dev/Blog?id=zuhnoflygz This article discussions using a package hosted on OnePub from other packages/apps. https://onepub.dev/Blog?id=yvuhnoflyg 2. Use melos + monorepo (hosted on bitbucket) to manage versioning / changelogs etc of our packages. This is really outside the scope of OnePub. If you follow the above guidelines on publishing a package then it will work within melos. Melos simply allows you to have a single git repo containing multiple packages. Each package has its own pubspec.yaml. Just use the process described above to mark each of the pubspec.yaml as publishing to OnePub (using the `onepub pub private` command) and then melos will work as expected. 3. Publish (private) to OnePub via CI/DC when commits are merged into our main branch. This is a very common use case, the OnePub manual details how to set this up. https://docs.onepub.dev/guides/ci-cd Hopefully that makes sense, if not send me some follow up questions. Happy to help you get up and running.

…

On Thu, Feb 1, 2024 at 7:54 PM Richard James Beanland < ***@***.***> wrote: Hello, I am looking for some examples and / or guidance on how to achieve the following setup. We want to: 1. Host private dart and flutter packages for members of the team to access in our various apps. These packages need to be versioned with all previous versions also accessible. 2. Use melos + monorepo (hosted on bitbucket) to manage versioning / changelogs etc of our packages. 3. Publish (private) to OnePub via CI/DC when commits are merged into our main branch. Is there any documentation or guidance on how this might be achieved? Thanks, Rich — Reply to this email directly, view it on GitHub <#531>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OEUD2JDF2FVA4OGZ7LYRNJ2RAVCNFSM6AAAAABCUPSUNSVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGE3DKOBRGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ObserverMoment]

Hi @bsutton , thanks for such a rapid answer!

I am considering this flow and wondered if you could comment.

• Bitbucket repo = mono-repo of all packages. Each package has a pubspec.yaml etc with its own version number.

When branch is merged into main we run a Bitbucket pipeline which uses the one pub cli to private publish packages to onepub.
Either we publish
- All packages or
- Just packages that are affected by merged commits (preferred)

Do you have any example code of how to achieve this, specifically with Bitbucket in mind?

How would you suggest to manage versioning? Is there some protection against overwriting published package versions on one pub with new code?

Thanks again! I am trying to convince management to opt for one pub rather than manual repo references so any direct instructions you can give would be really helpful!

Rich

[bsutton]

So we don't have any bit bucket pipeline examples. We actually use dart scripts to do our builds. As a result our github actions are very simple - the action just starts the dart build scripts - and we can use the same build scripts locally. The added bonus is that we don't have to learn another language and testing of the pipeline is much faster and you can debug it. https://onepub.dev/Blog?id=kjjbxpsdav Onepub won't let you overwrite an existing version. They pub publish command will fail. My advice would be to publish every package everytime with synchronised version numbers. Having the same version numbers makes it easy for users to work out what version of packages to import.

…

On Sat, 3 Feb 2024, 2:16 am Richard James Beanland, < ***@***.***> wrote: Hi @bsutton <https://github.com/bsutton> , thanks for such a rapid answer! I am considering this flow and wondered if you could comment. - Bitbucket repo = mono-repo of all packages. Each package has a pubspec.yaml etc with its own version number. When branch is merged into main we run a Bitbucket pipeline which uses the one pub cli to private publish packages to onepub. Either we publish - All packages or - Just packages that are affected by merged commits (preferred) Do you have any example code of how to achieve this, specifically with Bitbucket in mind? How would you suggest to manage versioning? Is there some protection against overwriting published package versions on one pub with new code? Thanks again! I am trying to convince management to opt for one pub rather than manual repo references so any direct instructions you can give would be really helpful! Rich — Reply to this email directly, view it on GitHub <#531 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32ODZLW3HP6S3EUC7OXDYRT7LFAVCNFSM6AAAAABCUPSUNSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGNBXGY4TG> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ObserverMoment]

Ok, thanks for info.

We are specifically trying to move away from hard syncing all packages to the same version number, and to make developer interaction much more similar to standard pub.dev.

[bsutton]

Onepub will work either way, so in the end, do what works best for your team.

…

On Tue, 6 Feb 2024, 2:37 am Richard James Beanland, < ***@***.***> wrote: Ok, thanks for info. We are specifically trying to move away from hard syncing all packages to the same version number, and to make developer interaction much more similar to standard pub.dev. — Reply to this email directly, view it on GitHub <#531 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OCG7BXAUWRQ4IE6DQDYSD4C5AVCNFSM6AAAAABCUPSUNSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGNZRHE4DS> . You are receiving this because you were mentioned.Message ID: ***@***.***>