This is the package layout recommended for custom packages:
<root>
├── package.json
├── README.md
├── CHANGELOG.md
├── LICENSE.md
├── Third Party Notices.md
├── Editor
│ ├── [company-name].[package-name].Editor.asmdef
│ └── EditorExample.cs
├── Runtime
│ ├── [company-name].[package-name].asmdef
│ └── RuntimeExample.cs
├── Tests
│ ├── Editor
│ │ ├── [company-name].[package-name].Editor.Tests.asmdef
│ │ └── EditorExampleTest.cs
│ └── Runtime
│ ├── [company-name].[package-name].Tests.asmdef
│ └── RuntimeExampleTest.cs
├── Samples~
│ ├── SampleFolder1
│ ├── SampleFolder2
│ └── ...
└── Documentation~
└── [package-name].md
Many official Unity packages also implement this structure.
| Location | Description |
|---|---|
package.json |
The package manifestEach package has a manifest, which provides information about the package to the Package Manager. The manifest contains information such as the name of the package, its version, a description for users, dependencies on other packages (if any), and other details. More info See in Glossary, which defines the package dependenciesIn the context of the Package Manager, a dependency is a specific package version (expressed in the form package_name@package_version) that a project or another package requires in order to work. Projects and packages use the dependencies attribute in their manifests to define the set of packages they require. For projects, these are considered direct dependencies; for packages, these are indirect, or transitive, dependencies. More infoSee in Glossary and other metadata. |
README.md |
Developer package documentation. This is generally documentation to help developers who want to modify the package or push a new change on the package master source repository. |
CHANGELOG.md |
Description of package changes in reverse chronological order. It is good practice to use a standard format, like Keep a Changelog. |
LICENSE.md |
Contains the package license text. Usually the Package Manager copies the text from the selected SPDX list website. |
Editor/ |
Editor platform-specific Assets folder. Unlike Editor folders under Assets, this is only a convention and does not affect the Asset import pipeline. See Assembly definition and packages to properly configure Editor-specific assemblies in this folder. |
Runtime/ |
Runtime platform-specific Assets folder. This is only a convention and does not affect the Asset import pipeline. See Assembly definition and packages to properly configure runtime assemblies in this folder. |
Tests/ |
Folder to store any tests included in the package. |
Tests/Editor/ |
Editor platform specific tests folder. See Assembly definition and packages to properly configure Editor-specific test assemblies in this folder. |
Tests/Runtime/ |
Runtime platform specific tests. See Assembly definition and packages to properly configure runtime test assemblies in this folder. |
Samples~/ |
Folder to store any samples included in the package. |
Documentation~ |
Folder to store any documentation included in the package. |
Unity ignores the contents of any folder name that ends with the ~ character and does not track them with .meta files. However, you need to include .meta files for the Editor, Runtime, and Tests folders and their contents in order for them to work properly. For more information on .meta files and how Unity uses them for tracking, see Asset workflow.