Creating packages

The pack command

Creating a package from a module is very simple, just run the pack command from the root of the cluster.

Warning

Modules that are published as packages must have a root namespace defined.

Example to create a package for the Party module:

neos pack Party

This creates Party.nupkg at the root of the cluster.

You can specify a name for the generated package (version number management is explained in the following chapter) :

neos pack Party --output party.1.15.4.nupkg

The file created is then Party.1.15.4.nupkg, again at the root of the cluster.

You can specify a folder for the generated package:

neos pack Party --output D:/packages

The created file is then D:/packages/Party.nupkg.

You can specify a folder and a name for the generated package:

neos pack Party --output D:/packages/party.1.15.4.nupkg

The created file is then D:/packages/Party.1.15.4.nupkg.

Note

The generated package contains a tag of type neos:X.Y.Z where X.Y.Z is the version of Neos with which the package was generated. The package can only be used on X.Y.* versions of Neos unless control has been disabled.

How is the version generated?

You can specify a version for a module in Neos Studio. If this property is set, it will be used as the version of the generated package. When this property is not specified, the version of the cluster is used as the version of the generated package.

How dependencies are generated?

The package dependencies are exactly the same as the module dependencies. This means that if a module B that depends on a module A is published as a package, module A must also be published as a package.

It is possible to define a version constraint for module dependencies in Neos Studio. This version property must respect a specific format (interval notation). As you can read in the documentation, if you specify a version X.Y.Z for a reference to a module A, this means that you want A >= X.Y.Z. If you want module A in version X.Y.Z exactly, you must specify [X.Y.Z].

When this property is not filled in, the version of the referenced module is used (or, failing that, the version of the cluster).

How to customize the contents of the package?

The module directory contains files/folders that you do not want to find in your NuGet package. This could be temporary compilation files, for example.

By default, here is the list of ignored paths or files:

*.Tests.UnitTests/
*.gen.props
bin/
obj/
endToEndTests/
metadata/Features/
metadata/FeatureGroups/
metadata/UIViewScenarios/

In addition to this list, to determine which files to ignore, the processing looks for a .nupkgignore or .gitignore file in the module directory or in a parent directory. The file found closest in the hierarchy is used, with priority given to the .nupkgignore file over the .gitignore file.

The format of the .nupkgignore file is the same as that of the .gitignore file (format definition).

.nupkgignore file example to ignore unit test projects, generated props files, VS-generated files and automation test projects:

path_to_ignore/

The complete list of ignored paths or files will be :

*.Tests.UnitTests/
*.gen.props
bin/
obj/
endToEndTests/
metadata/Features/
metadata/FeatureGroups/
metadata/UIViewScenarios/
path_to_ignore/