The first important thing to point out about a Dart package project structure is that its validity is asserted by the presence of a pubspec.yaml file; that is, if there's a pubspec.yaml file in your structure, then there is a package and this is where you properly describe it—without it, there's no package at all. This is what a typical package looks like:

For application packages, there is no required project layout to adopt (as it's not intended to be published to the pub repository); however, as it is evolving, there's already several recommended ways and conventions to follow. Let's take a look at the common structure of a general Dart package. Most of the structure is conventional and depends on your project complexity and whether you want to share its code in some way. 

Let's take a look at the role of each file and directory in a typical Dart package structure:

• pubspec.yaml: As already pointed out, this is the fundamental package file and it describes the package to the pub repository. We will be examining the full structure of this file in more detail later.
• The lib/ and lib/src/ directories: These are the places where the package library source code lives. As you already know, a simple .dart file is a small library, so everything you put in the lib directory is publicly available to other packages. This is known as the package public API. The src subdirectory contains, by convention, all of the internal package code, that is, the private source code of the package that is not meant to be directly imported by others.

• lib/simple_package_structure.dart: A common practice is to add a single, or a few, top-level files that export (remember the export statement) the local src/libraries. The name of this file is typically the same as the package. If there is more than one library, then the name must be simple enough to identify the general purpose of the exported libraries.
• test/: Unit tests and benchmark analysis are conventionally put inside the test and benchmark directories, respectively. Additionally, the source code inside the test folder is typically postfixed with the _test identifier.

• README.md, CHANGELOG.md, and LICENSE: These are markdown files typically present in packages that are intended to be published in some public repository, such as the Dart pub. These files are also very common in open source projects. The LICENSE file, which specifies the source code copyright information, is also sometimes present.
• example/: This is important in published packages and can demonstrate how the package can be used.
• analysis_options.yaml: This is a useful file to customize the lint checks, style analysis, and other precompile checks.

Some additional files depend on the purpose of the project, including the following:

• tools/: This is a directory containing scripts that can be used during development, including utilities to manipulate images, raw files, and any kind of script that is private to the package and useful to the developer.
• doc/ and doc/api: This is where you can add some useful information about the project. api/ subdirectory is where the dartdoc tool (presented in Chapter 1, An Introduction to Dart) generates the API documentation based on code comments.

In web packages, some new files and directories are included; they are as follows:

• The lib/ folder is the typical destination of static web resource files, such as images or .css files.
• web/ is a directory used in web application projects. Unlike the lib/ folder, which is meant to be library code, this code is meant to have the web application source code and entry points (that is, the main() function).

In command-line packages, the bin directory is included:

• The bin/ directory is meant to have some script that can run directly from the command line; the Stagehand tool described next is an example of the command-line library tool.