This proposal suggests adding a new sub-command, named 'modify', under elastic-package that can make arbitrary modifications to packages. These changes can include things like updating the ECS version, updating the package spec version, generating tags for pipeline processors, applying best practices, and so on.

I've created a proof-of-concept for this proposal which can be found in the feat/modify-cmd branch of my fork of elastic-package.

The actual work performed by the modify sub-command is defined under packages in the internal/modfiy package. For example, a modifier for generating ingest pipeline tags would be found under internal/modfiy/pipelinetag. Each modifier would provide a struct defined by internal/modfiy, which describes the modifier itself and provides a Run function which performs the actual work:

type Modifier struct {
	Name     string
	Doc      string
	Flags    pflag.FlagSet
	Run      func(pkg *fleetpkg.Package) error
}

These structs are then registered when creating the modify sub-command in setupModifyCommand()in the cmd package.

If a modifier requires additional arguments, such as the ECS version modifier, those arguments may be registered as flags. These flags will have the modifier name prefixed to them to avoid issues with ambiguous names. For example, a version flag from a modifier named ecs-update would have a flag --ecs-update.version.

In addition to the actual modify sub-command, additional supporting packages have been created to aid in applying modifications:

• internal/fleetpkg: Provides a package for types for fleet integrations, along with functions for loading integrations from the filesystem.
• internal/yamledit: Provides a package for reading, modifying, and writing YAML ASTs.