Status Quo

• A project is a directory of files, uniquely identified by a hash of all files. Projects can export any number of compilation artifacts and packages.
• A dependency is a directed edge between projects. A project may depend on any number of projects. A project may be a dependency of any number of projects.
• A package is a directory of files, along with a root source file that identifies the file referred to when the package is used with @import.
• A compilation artifact is a static library, a dynamic library, an executable, or an object file. Corresponds to std.build.LibExeObjStep.

The Problem

We have been using the word "package" already, including in build system APIs:

However, people are 100% going to say "package" when they mean "project". This is unavoidable, inescapable, and we should not fight against it, but rather embrace it. That leaves us with the following lingo:

• A package is a directory of files, uniquely identified by a hash of all files. Packages can export any number of compilation artifacts and packages.
• A package is a directory of files, along with a root source file that identifies the file referred to when the package is used with @import.

Ambiguity strikes ruthlessly.

The Solution

Our hero is the word "module". The word "project" is no longer needed.

• A package is a directory of files, uniquely identified by a hash of all files. Packages can export any number of compilation artifacts and modules.
• A dependency is a directed edge between packages. A package may depend on any number of packages. A package may be a dependency of any number of packages.
• A module is a directory of files, along with a root source file that identifies the file referred to when the module is used with @import.
• A compilation artifact is a static library, a dynamic library, an executable, or an object file. Corresponds to std.build.LibExeObjStep.

I would also like to rename LibExeObjStep to CompilationArtifact while we're at it.

This issue is to do the following things:

• update the terminology in documentation
• update the terminology in the zig compiler internal source code
• update the terminology in the build system APIs and internal source code
• update the terminology in build.zig.zon
• update the CLI arguments