The initial implementation of the project file and project assembly (see #2510, #2886, #2877 for the bulk of that work) was only the first step in retooling how Miden Assembly projects and packages are defined and assembled. There is not only additional refactoring/clean-up work to be done (e.g. removal of Library and Program), but there are still various edge cases/bugs to be addressed. This issue is being set up to track that remaining work.

This issue is NOT for discussion on the individual issues. Instead, take that to the individual sub-tasks. However, if there are missing tasks that you feel should be tracked here, feel free to leave a comment so we can discuss whether to track it as part of this issue, or if it should be treated as a separate standalone task.

Goals

What we're aiming for with projects/project assembly, is the following:

• Existing MASM libraries/programs are defined in terms of projects, and assemble to packages (i.e. .masp artifact). Assembly of standalone MASM files will remain supported to some degree, but may require more manual configuration in order to provide necessary information we'd otherwise expect to get from project files.
• Most, if not all, package/dependency management workflows are well-tested and stable. This primarily refers to the ability to depend on other packages via any of the supported schemes, without any significant bugs in the dependency solver. While this is largely the case now, there are still some edge cases that may produce errors.
• Support for local system-wide package management via feat: local package registry implementation #2881, this will not only make many workflows more natural, but will provide a stepping stone towards an eventual canonical package registry (may or may not be built by us, but the tooling should be in place for someone to build it).
• Ultimately, simplification of the assembler itself, as more information is made available to it up front