refactor: optimize clean command by precomputing paths to clean

[suojae]

Description

This PR optimizes the _cleanPackage method by precomputing the paths to clean (pathsToClean) before iterating through them. Specifically, relative paths are joined with the package root using p.join ahead of time, avoiding repeated path computations during the loop.

Key Changes:

Precomputing Paths:

• pathsToClean now contains fully resolved paths created by combining relative paths (cleanablePubFilePaths and .dart_tool) with the package root.
• This eliminates the need for p.join operations inside the loop, improving both performance and code readability.

---

Type of Change

• ✨ feat -- New feature (non-breaking change which adds functionality)
• 🛠️ fix -- Bug fix (non-breaking change which fixes an issue)
• ❌ ! -- Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 refactor -- Code refactor
• ✅ ci -- Build configuration change
• 📝 docs -- Documentation
• 🗑️ chore -- Chore

---

Checklist

• I have read the [CONTRIBUTING](https://github.com/invertase/melos/blob/main/CONTRIBUTING.md) guidelines.
• I have read the [Invertase's Code of Conduct](https://github.com/invertase/meta/blob/main/CODE_OF_CONDUCT.md).
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary documentation (if applicable).
• I have run melos bootstrap and confirmed it is working as expected locally.

[docs-page]

To view this pull requests documentation preview, visit the following URL:

docs.page/invertase/melos~855

Documentation is deployed and generated using docs.page.

[spydon]

I think this change is fine, but I fail to see how this would improve performance, since it now has to loop two times over the list.

[suojae]

I see your point that the new implementation maps the list before the loop, resulting in two iterations. However, I believe the benefit lies in reducing repeated p.join calls, which streamlines the logic and separates I/O operations from path preparation. I think this can contribute to maintenance by reducing the overhead of I/O work and logically separating it.

[spydon]

I see your point that the new implementation maps the list before the loop, resulting in two iterations. However, I believe the benefit lies in reducing repeated p.join calls, which streamlines the logic and separates I/O operations from path preparation. I think this can contribute to maintenance by reducing the overhead of I/O work and logically separating it.

It's actually not running two loops now when I think about it, since map is executed lazily.

However, I believe the benefit lies in reducing repeated p.join calls

It should still be doing exactly the same amount of p.join calls as before, once per file?

[suojae]

You're absolutely right—map is lazily evaluated, so it doesn’t run two loops in practice. And yes, the p.join calls are still executed once per file, so there’s no additional overhead in terms of performance.

For me, separating the path-building logic from the actual I/O operation made the code clearer and easier to maintain, especially if we need to extend or modify the logic in the future. That said, I completely understand if the team prefers the original style—I'm happy to adjust as needed!