When working with package commands, it's not unlikely to run into errors and issues. Here is a compilation of common errors that may occur, along with solutions to those errors.

Common Package Errors and Fixes

The package ID or Alias ID is invalid OR The subscriber version ID or package version ID isn't defined

• The package version ids may be specific to a DevHub that does not allow them to be installed in another company's environments. This can happen on open source projects where the package IDs and version IDs are listed in the packageAliases section of open source SFDX projects

• To fix this, you would need to remove all of the IDs of packages and versions you have not created, and re-package them for yourself. Add your own IDs to the local sfdx-project.json

"Package" isn't defined in the sfdx-project.json. Add it to the packagedirectories section and add the alias to packageAliases with its 0Ho ID.

• Same problem as above. Your own DevHub doesn't recognize the packages that were created and versioned in another DevHub

It's possible that the package was created on a different Dev Hub. Authenticate to the Dev Hub org that owns the package, and reference that Dev Hub when running the command

• Same as problems from above. You have to recreate all of the packages from your own DevHub, and reference those IDs only.

This Directory does not contain a valid Salesforce DX project

• This happened if I tried to edit in a path that wasn't correct. Sometimes, when I opened a project, VSCode would open up the repo without the correct path. To fix this I just did "cd .\InsertFolderNameHere"

• Always double check that you are working in the path where your SFDX project is located

Path must be a string, received null

• It fixed itself when I edited the contents within the package directory folder, and then restarted VScode.I assume it's because a path is considered empty / doesn't have enough contents for a proper package.

Expected path

• This error occurred when I tried to version a package, and the path I referred to was different than the path in the sfdx-project.json file. It has to be exactly the same. I refereed "./forceapp1" in my command, however, in the file, it was just "forceapp1" without the "./"

Package Root directory empty

• This occurred when I created a package, and the folder for the package directory was empty. When I created an empty file inside of the directory and entered in a few random lines of cold, the error went away.

Creating and Configuring Unlocked Package

Managing packages in their sfdx-project.json file is a vital part of the development process. The process of involving dependencies, versioning, and installation can all become very confusing. This page breaks down the process in a digestible way, so that you can easily create, version, and install packages.

Package Version Numbers:

• NEXT: increment the build number to the next available for the package

• LATEST: assign the latest version of the package

Dependencies

• By default, when referencing a certain Standard Object, field, or component type, you will generate a prerequisite dependency on your package

Package Installation Key:

• ensures the security of the metadata within the package. Authorized Users are then provided the key

• Provide -k (installation key) when running sfdx force:package:version:create. This key must be supplied when installing the package in an org.

• Installation keys can be changed by running sfdx force:package:version:update

NameSpaces

• Distinguishes your package and its contents from packages of other developers

• Creating a "no namespace" package gives developers more control over how to organize and distribute parts of an application. Existing unpackaged metadata can be migrated only to an unlocked package with no namespace.

Creating the Package

Generate

• sfdx force:package:create

• Make sure you specify the -name, -packagetype, -path, and -description.

• specify feature and org preferences for the metadata in your sfdx-project.json

Release

• sfdx force:package:version:create

• Make sure you specify the -package, -installationkey, -wait, and any optional variables you wish to update

• Use the "-b" flag to specify a build on a "logical branch". This flag allows you to keep experimental/development builds separate from the "main stream" builds that would be generated from your GIT MASTER branch

Install

• sfdx force:package:install

• Make sure you specify the package version by running sfdx:force:package:version:list to find its 0Ho ID.

• Install packages in order of dependencies

Best Practices

• Include the -tag option when you use the package:version:create and package:version:update commands. This option helps you keep your version-control system tags in sync with specific package versions.

• Keep your sfdx-project.json populated with important information such as versions, name, build, aliases, etc. This is your source of truth for all packages.

• use -wait when creating package versions. This helps you avoid the process of having to run sfdx force:version:report:create in order to view your package's status.

• Don't version every little feature or change. Your org has a maximum number of package commands you can run.

• Avoid namespaces if you aren't accustomed to them

• Specify PermissionSets within your packages

• Refer to the CLI Command Reference when running sfdx commands

• Refer to the Scratch Org and DevHub Reference when using Scratch Org

• Adopt a robust .forceignore file to avoid pulling down unwanted metadata

• Have developers religiously refer to the Metadata Coverage Report to avoid packaging metadata this is incompatible with packaging.