Issues in Composer.php (master) - Issues in master - EvilFreelancer/composer-json-generator - Measure and Improve Code Quality continuously with Scrutinizer

Issues (12)

Security Analysis no request data

Cross-Site Scripting

Cross-Site Scripting enables an attacker to inject code into the response of a web-request that is viewed by other users. It can for example be used to bypass access controls, or even to take over other users' accounts.

File Exposure

File Exposure allows an attacker to gain access to local files that he should not be able to access. These files can for example include database credentials, or other configuration files.

File Manipulation

File Manipulation enables an attacker to write custom data to files. This potentially leads to injection of arbitrary code on the server.

Object Injection

Object Injection enables an attacker to inject an object into PHP code, and can lead to arbitrary code execution, file exposure, or file manipulation attacks.

Code Injection

Code Injection enables an attacker to execute arbitrary code on the server.

Response Splitting

Response Splitting can be used to send arbitrary responses.

File Inclusion

File Inclusion enables an attacker to inject custom files into PHP's file loading mechanism, either explicitly passed to include, or for example via PHP's auto-loading mechanism.

Command Injection

Command Injection enables an attacker to inject a shell command that is execute with the privileges of the web-server. This can be used to expose sensitive data, or gain access of your server.

SQL Injection

SQL Injection enables an attacker to execute arbitrary SQL code on your database server gaining access to user data, or manipulating user data.

XPath Injection

XPath Injection enables an attacker to modify the parts of XML document that are read. If that XML document is for example used for authentication, this can lead to further vulnerabilities similar to SQL Injection.

LDAP Injection

LDAP Injection enables an attacker to inject LDAP statements potentially granting permission to run unauthorized queries, or modify content inside the LDAP tree.

Header Injection

Other Vulnerability

This category comprises other attack vectors such as manipulating the PHP runtime, loading custom extensions, freezing the runtime, or similar.

Regex Injection

Regex Injection enables an attacker to execute arbitrary code in your PHP process.

XML Injection

XML Injection enables an attacker to read files on your local filesystem including configuration files, or can be abused to freeze your web-server process.

Variable Injection

Variable Injection enables an attacker to overwrite program variables with custom data, and can lead to further vulnerabilities.

Unfortunately, the security analysis is currently not available for your project. If you are a non-commercial open-source project, please contact support to gain access.

src/Schemas/Composer.php (1 issue)

Labels

Bug 1

Severity

Critical 1

Upgrade to new PHP Analysis Engine

These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more

<?php

namespace ComposerJson\Schemas;

use ComposerJson\Model;
use phpDocumentor\Reflection\Types\Array_;

class Composer extends Model
{
    /**
     * The name of the package. It consists of vendor name and project name, separated by /. Examples:
     *
     * monolog/monolog
     * igorw/event-source
     *
     * The name can contain any character, including white spaces, and it's case insensitive (foo/bar and Foo/Bar are considered the same package). In order to simplify
     * its installation, it's recommended to define a short and lowercase name that doesn't include non-alphanumeric characters or white spaces.
     *
     * Required for published packages (libraries).
     *
     * @var string
     */
    public ?string $name;


    /**
     * A short description of the package. Usually this is one line long.
     *
     * Required for published packages (libraries).
     *
     * @var string
     */
    public ?string $description;

    /**
     * The version of the package. In most cases this is not required and should be omitted (see below).
     *
     * This must follow the format of X.Y.Z or vX.Y.Z with an optional suffix of -dev, -patch (-p), -alpha (-a), -beta (-b) or -RC. The patch, alpha, beta and RC
     * suffixes can also be followed by a number.
     *
     * Examples:
     *
     * 1.0.0
     * 1.0.2
     * 1.1.0
     * 0.2.5
     * 1.0.0-dev
     * 1.0.0-alpha3
     * 1.0.0-beta2
     * 1.0.0-RC5
     * v2.0.4-p1
     *
     * Optional if the package repository can infer the version from somewhere, such as the VCS tag name in the VCS repository. In that case it is also recommended to
     * omit it.
     *
     * Note: Packagist uses VCS repositories, so the statement above is very much true for Packagist as well. Specifying the version yourself will most likely end up
     * creating problems at some point due to human error.
     *
     * @var string
     */
    public ?string $version;

    /**
     * The type of the package. It defaults to library.
     *
     * Package types are used for custom installation logic. If you have a package that needs some special logic, you can define a custom type. This could be a
     * symfony-bundle, a wordpress-plugin or a typo3-cms-extension. These types will all be specific to certain projects, and they will need to provide an installer
     * capable of installing packages of that type.
     *
     * Out of the box, Composer supports four types:
     *
     * library: This is the default. It will simply copy the files to vendor.
     * project: This denotes a project rather than a library. For example application shells like the Symfony standard edition, CMSs like the SilverStripe installer or
     * full fledged applications distributed as packages. This can for example be used by IDEs to provide listings of projects to initialize when creating a new
     * workspace. metapackage: An empty package that contains requirements and will trigger their installation, but contains no files and will not write anything to the
     * filesystem. As such, it does not require a dist or source key to be installable. composer-plugin: A package of type composer-plugin may provide an installer for
     * other packages that have a custom type. Read more in the dedicated article.
     *
     * Only use a custom type if you need custom logic during installation. It is recommended to omit this field and have it default to library.
     *
     * @var string
     */
    public ?string $type;

    /**
     * An array of keywords that the package is related to. These can be used for searching and filtering.
     *
     * Examples:
     *
     * logging
     * events
     * database
     * redis
     * templating
     *
     * Optional.
     *
     * @var array
     */
    public array $keywords = [];

    /**
     * An URL to the website of the project.
     *
     * Optional.
     *
     * @var string
     */
    public ?string $homepage;

    /**
     * A relative path to the readme document.
     *
     * Optional.
     *
     * @var string
     */
    public ?string $readme;

    /**
     * Release date of the version.
     *
     * Must be in YYYY-MM-DD or YYYY-MM-DD HH:MM:SS format.
     *
     * Optional.
     *
     * @var ?string
     */
    public ?string $time;

    /**
     * The license of the package. This can be either a string or an array of strings.
     *
     * The recommended notation for the most common licenses is (alphabetical):
     *
     * Apache-2.0
     * BSD-2-Clause
     * BSD-3-Clause
     * BSD-4-Clause
     * GPL-2.0-only / GPL-2.0-or-later
     * GPL-3.0-only / GPL-3.0-or-later
     * LGPL-2.1-only / LGPL-2.1-or-later
     * LGPL-3.0-only / LGPL-3.0-or-later
     * MIT
     *
     * Optional, but it is highly recommended to supply this. More identifiers are listed at the SPDX Open Source License Registry.
     *
     * For closed-source software, you may use "proprietary" as the license identifier.
     *
     * @var string|string[]
     */
    public $license;

    /**
     * The authors of the package. This is an array of objects.
     *
     * Each author object can have following properties:
     *
     * name: The author's name. Usually their real name.
     * email: The author's email address.
     * homepage: An URL to the author's website.
     * role: The author's role in the project (e.g. developer or translator)
     *
     * @var \ComposerJson\Schemas\Author[]
     */
    public array $authors = [];

    /**
     * Various information to get support about the project.
     *
     * Support information includes the following:
     *
     * email: Email address for support.
     * issues: URL to the issue tracker.
     * forum: URL to the forum.
     * wiki: URL to the wiki.
     * irc: IRC channel for support, as irc://server/channel.
     * source: URL to browse or download the sources.
     * docs: URL to the documentation.
     * rss: URL to the RSS feed.
     * chat: URL to the chat channel.
     *
     * @var \ComposerJson\Schemas\Support
     */
    public $support;

    /**
     * Lists packages required by this package. The package will not be installed unless those requirements can be met.
     *
     * @var array
     */
    public array $require = [];

    /**
     * Lists packages required for developing this package, or running tests, etc. The dev requirements of the root package are installed by default. Both install or
     * update support the --no-dev option that prevents dev dependencies from being installed.
     *
     * @var array
     */
    public array $requireDev = [];

    /**
     * Lists packages that conflict with this version of this package. They will not be allowed to be installed together with your package.
     *
     * Note that when specifying ranges like <1.0 >=1.1 in a conflict link, this will state a conflict with all versions that are less than 1.0 and equal or newer than
     * 1.1 at the same time, which is probably not what you want. You probably want to go for <1.0 || >=1.1 in this case.
     *
     * @var array
     */
    public array $conflict = [];

    /**
     * Lists packages that are replaced by this package. This allows you to fork a package, publish it under a different name with its own version numbers, while
     * packages requiring the original package continue to work with your fork because it replaces the original package.
     *
     * This is also useful for packages that contain sub-packages, for example the main symfony/symfony package contains all the Symfony Components which are also
     * available as individual packages. If you require the main package it will automatically fulfill any requirement of one of the individual components, since it
     * replaces them.
     *
     * Caution is advised when using replace for the sub-package purpose explained above. You should then typically only replace using self.version as a version
     * constraint, to make sure the main package only replaces the sub-packages of that exact version, and not any other version, which would be incorrect.
     *
     * @var array
     */
    public array $replace = [];

    /**
     * List of other packages that are provided by this package. This is mostly useful for common interfaces. A package could depend on some virtual logger package, any
     * library that implements this logger interface would simply list it in provide.
     *
     * @var array
     */
    public array $provide = [];

    /**
     * Suggested packages that can enhance or work well with this package. These are informational and are displayed after the package is installed, to give your users a
     * hint that they could add more packages, even though they are not strictly required.
     *
     * The format is like package links above, except that the values are free text and not version constraints.
     *
     * @var array
     */
    public array $suggest = [];

    /**
     * Autoload mapping for a PHP autoloader.
     *
     * PSR-4 and PSR-0 autoloading, classmap generation and files includes are supported.
     *
     * PSR-4 is the recommended way since it offers greater ease of use (no need to regenerate the autoloader when you add classes).
     *
     * @var \ComposerJson\Schemas\AutoloadInterface[]
     */
    public array $autoload = [];

    /**
     * This section allows to define autoload rules for development purposes.
     *
     * Classes needed to run the test suite should not be included in the main autoload rules to avoid polluting the autoloader in production and when other people use
     * your package as a dependency.
     *
     * Therefore, it is a good idea to rely on a dedicated path for your unit tests and to add it within the autoload-dev section.
     *
     * @var \ComposerJson\Schemas\AutoloadInterface[]
     */
    public array $autoloadDev = [];

    /**
     * DEPRECATED: This is only present to support legacy projects, and all new code should preferably use autoloading. As such it is a deprecated practice, but the
     * feature itself will not likely disappear from Composer.
     *
     * A list of paths which should get appended to PHP's include_path.
     *
     * @var array
     */
    public array $includePath = [];

    /**
     * DEPRECATED: This is only present to support legacy PSR-0 style autoloading, and all new code should preferably use PSR-4 without target-dir and projects using
     * PSR-0 with PHP namespaces are encouraged to migrate to PSR-4 instead.
     *
     * Defines the installation target.
     *
     * In case the package root is below the namespace declaration you cannot autoload properly. target-dir solves this problem.
     *
     * An example is Symfony. There are individual packages for the components. The Yaml component is under Symfony\Component\Yaml. The package root is that Yaml
     * directory. To make autoloading possible, we need to make sure that it is not installed into vendor/symfony/yaml, but instead into
     * vendor/symfony/yaml/Symfony/Component/Yaml, so that the autoloader can load it from vendor/symfony/yaml.
     *
     * @var string
     */
    public ?string $targetDir;

    /**
     * This defines the default behavior for filtering packages by stability. This defaults to stable, so if you rely on a dev package, you should specify it in your
     * file to avoid surprises.
     *
     * All versions of each package are checked for stability, and those that are less stable than the minimum-stability setting will be ignored when resolving your
     * project dependencies. (Note that you can also specify stability requirements on a per-package basis using stability flags in the version constraints that you
     * specify in a require block (see package links for more details).
     *
     * Available options (in order of stability) are dev, alpha, beta, RC, and stable.
     *
     * @var string
     */
    public ?string $minimumStability;

    /**
     * When this is enabled, Composer will prefer more stable packages over unstable ones when finding compatible stable packages is possible. If you require a dev
     * version or only alphas are available for a package, those will still be selected granted that the minimum-stability allows for it.
     *
     * Use "prefer-stable": true to enable.
     *
     * @var bool
     */
    public bool $preferStable;

    /**
     * Custom package repositories to use.
     *
     * By default Composer only uses the packagist repository. By specifying repositories you can get packages from elsewhere.
     *
     * Repositories are not resolved recursively. You can only add them to your main composer.json. Repository declarations of dependencies' composer.jsons are ignored.
     *
     * The following repository types are supported:
     *
     * composer: A Composer repository is simply a packages.json file served via the network (HTTP, FTP, SSH), that contains a list of composer.json objects with
     * additional dist and/or source information. The packages.json file is loaded using a PHP stream. You can set extra options on that stream using the options
     * parameter. vcs: The version control system repository can fetch packages from git, svn, fossil and hg repositories. pear: With this you can import any pear
     * repository into your Composer project. package: If you depend on a project that does not have any support for composer whatsoever you can define the package
     * inline using a package repository. You basically inline the composer.json object.
     *
     * @var \ComposerJson\Schemas\Repository[]
     */
    public array $repositories = [];

    /**
     * A set of configuration options. It is only used for projects. See Config for a description of each individual option.
     *
     * @var array
     */
    public array $config = [];

    /**
     * Composer allows you to hook into various parts of the installation process through the use of scripts.
     *
     * See Scripts for events details and examples
     *
     * @var array
     */
    public array $scripts = [];

    /**
     * Arbitrary extra data for consumption by scripts.
     *
     * This can be virtually anything. To access it from within a script event handler, you can do:
     *
     * $extra = $event->getComposer()->getPackage()->getExtra();
     *
     * Optional.
     *
     * @var array
     */
    public array $extra = [];

    /**
     * A set of files that should be treated as binaries and symlinked into the bin-dir (from config).
     *
     * See Vendor Binaries for more details.
     *
     * Optional.
     *
     * @var string|array
     */
    public $bin;

    /**
     * A set of options for creating package archives.
     *
     * The following options are supported:
     *
     * exclude: Allows configuring a list of patterns for excluded paths. The pattern syntax matches .gitignore files. A leading exclamation mark (!) will result in any
     * matching files to be included even if a previous pattern excluded them. A leading slash will only match at the beginning of the project relative path. An asterisk
     * will not expand to a directory separator.
     *
     * Optional.
     *
     * @var array
     */
    public array $archive = [];

    /**
     * Indicates whether this package has been abandoned.
     *
     * It can be boolean or a package name/URL pointing to a recommended alternative.
     *
     * Examples:
     *
     * Use "abandoned": true to indicates this package is abandoned. Use "abandoned": "monolog/monolog" to indicates this package is abandoned and the recommended
     * alternative is monolog/monolog.
     *
     * Defaults to false.
     *
     * Optional.
     *
     * @var bool|string
     */
    public $abandoned;

    /**
     * A list of regex patterns of branch names that are non-numeric (e.g. "latest" or something), that will NOT be handled as feature branches. This is an array of
     * strings.
     *
     * If you have non-numeric branch names, for example like "latest", "current", "latest-stable" or something, that do not look like a version number, then Composer
     * handles such branches as feature branches. This means it searches for parent branches, that look like a version or ends at special branches (like master) and the
     * root package version number becomes the version of the parent branch or at least master or something.
     *
     * To handle non-numeric named branches as versions instead of searching for a parent branch with a valid version or special branch name like master, you can set
     * patterns for branch names, that should be handled as dev version branches.
     *
     * This is really helpful when you have dependencies using "self.version", so that not dev-master, but the same branch is installed (in the example: latest-testing).
     *
     * Optional.
     *
     * @var array
     */
    public array $nonFeatureBranches = [];
}


1			<?php
2
3			namespace ComposerJson\Schemas;
4
5			use ComposerJson\Model;
6			use phpDocumentor\Reflection\Types\Array_;
7
8			class Composer extends Model
9			{
10			/**
11			* The name of the package. It consists of vendor name and project name, separated by /. Examples:
12			*
13			* monolog/monolog
14			* igorw/event-source
15			*
16			* The name can contain any character, including white spaces, and it's case insensitive (foo/bar and Foo/Bar are considered the same package). In order to simplify
17			* its installation, it's recommended to define a short and lowercase name that doesn't include non-alphanumeric characters or white spaces.
18			*
19			* Required for published packages (libraries).
20			*
21			* @var string
22			*/
23			public ?string $name;
			0 ignored issues – show Bug introduced 2019-09-22 15:53 UTC by Report Bug Copy Issue Report Show Similar Issues like this This code did not parse for me. Apparently, there is an error somewhere around this line: Syntax error, unexpected '?', expecting T_FUNCTION or T_CONST Loading history...
24
25			/**
26			* A short description of the package. Usually this is one line long.
27			*
28			* Required for published packages (libraries).
29			*
30			* @var string
31			*/
32			public ?string $description;
33
34			/**
35			* The version of the package. In most cases this is not required and should be omitted (see below).
36			*
37			* This must follow the format of X.Y.Z or vX.Y.Z with an optional suffix of -dev, -patch (-p), -alpha (-a), -beta (-b) or -RC. The patch, alpha, beta and RC
38			* suffixes can also be followed by a number.
39			*
40			* Examples:
41			*
42			* 1.0.0
43			* 1.0.2
44			* 1.1.0
45			* 0.2.5
46			* 1.0.0-dev
47			* 1.0.0-alpha3
48			* 1.0.0-beta2
49			* 1.0.0-RC5
50			* v2.0.4-p1
51			*
52			* Optional if the package repository can infer the version from somewhere, such as the VCS tag name in the VCS repository. In that case it is also recommended to
53			* omit it.
54			*
55			* Note: Packagist uses VCS repositories, so the statement above is very much true for Packagist as well. Specifying the version yourself will most likely end up
56			* creating problems at some point due to human error.
57			*
58			* @var string
59			*/
60			public ?string $version;
61
62			/**
63			* The type of the package. It defaults to library.
64			*
65			* Package types are used for custom installation logic. If you have a package that needs some special logic, you can define a custom type. This could be a
66			* symfony-bundle, a wordpress-plugin or a typo3-cms-extension. These types will all be specific to certain projects, and they will need to provide an installer
67			* capable of installing packages of that type.
68			*
69			* Out of the box, Composer supports four types:
70			*
71			* library: This is the default. It will simply copy the files to vendor.
72			* project: This denotes a project rather than a library. For example application shells like the Symfony standard edition, CMSs like the SilverStripe installer or
73			* full fledged applications distributed as packages. This can for example be used by IDEs to provide listings of projects to initialize when creating a new
74			* workspace. metapackage: An empty package that contains requirements and will trigger their installation, but contains no files and will not write anything to the
75			* filesystem. As such, it does not require a dist or source key to be installable. composer-plugin: A package of type composer-plugin may provide an installer for
76			* other packages that have a custom type. Read more in the dedicated article.
77			*
78			* Only use a custom type if you need custom logic during installation. It is recommended to omit this field and have it default to library.
79			*
80			* @var string
81			*/
82			public ?string $type;
83
84			/**
85			* An array of keywords that the package is related to. These can be used for searching and filtering.
86			*
87			* Examples:
88			*
89			* logging
90			* events
91			* database
92			* redis
93			* templating
94			*
95			* Optional.
96			*
97			* @var array
98			*/
99			public array $keywords = [];
100
101			/**
102			* An URL to the website of the project.
103			*
104			* Optional.
105			*
106			* @var string
107			*/
108			public ?string $homepage;
109
110			/**
111			* A relative path to the readme document.
112			*
113			* Optional.
114			*
115			* @var string
116			*/
117			public ?string $readme;
118
119			/**
120			* Release date of the version.
121			*
122			* Must be in YYYY-MM-DD or YYYY-MM-DD HH:MM:SS format.
123			*
124			* Optional.
125			*
126			* @var ?string
127			*/
128			public ?string $time;
129
130			/**
131			* The license of the package. This can be either a string or an array of strings.
132			*
133			* The recommended notation for the most common licenses is (alphabetical):
134			*
135			* Apache-2.0
136			* BSD-2-Clause
137			* BSD-3-Clause
138			* BSD-4-Clause
139			* GPL-2.0-only / GPL-2.0-or-later
140			* GPL-3.0-only / GPL-3.0-or-later
141			* LGPL-2.1-only / LGPL-2.1-or-later
142			* LGPL-3.0-only / LGPL-3.0-or-later
143			* MIT
144			*
145			* Optional, but it is highly recommended to supply this. More identifiers are listed at the SPDX Open Source License Registry.
146			*
147			* For closed-source software, you may use "proprietary" as the license identifier.
148			*
149			* @var string\|string[]
150			*/
151			public $license;
152
153			/**
154			* The authors of the package. This is an array of objects.
155			*
156			* Each author object can have following properties:
157			*
158			* name: The author's name. Usually their real name.
159			* email: The author's email address.
160			* homepage: An URL to the author's website.
161			* role: The author's role in the project (e.g. developer or translator)
162			*
163			* @var \ComposerJson\Schemas\Author[]
164			*/
165			public array $authors = [];
166
167			/**
168			* Various information to get support about the project.
169			*
170			* Support information includes the following:
171			*
172			* email: Email address for support.
173			* issues: URL to the issue tracker.
174			* forum: URL to the forum.
175			* wiki: URL to the wiki.
176			* irc: IRC channel for support, as irc://server/channel.
177			* source: URL to browse or download the sources.
178			* docs: URL to the documentation.
179			* rss: URL to the RSS feed.
180			* chat: URL to the chat channel.
181			*
182			* @var \ComposerJson\Schemas\Support
183			*/
184			public $support;
185
186			/**
187			* Lists packages required by this package. The package will not be installed unless those requirements can be met.
188			*
189			* @var array
190			*/
191			public array $require = [];
192
193			/**
194			* Lists packages required for developing this package, or running tests, etc. The dev requirements of the root package are installed by default. Both install or
195			* update support the --no-dev option that prevents dev dependencies from being installed.
196			*
197			* @var array
198			*/
199			public array $requireDev = [];
200
201			/**
202			* Lists packages that conflict with this version of this package. They will not be allowed to be installed together with your package.
203			*
204			* Note that when specifying ranges like <1.0 >=1.1 in a conflict link, this will state a conflict with all versions that are less than 1.0 and equal or newer than
205			* 1.1 at the same time, which is probably not what you want. You probably want to go for <1.0 \|\| >=1.1 in this case.
206			*
207			* @var array
208			*/
209			public array $conflict = [];
210
211			/**
212			* Lists packages that are replaced by this package. This allows you to fork a package, publish it under a different name with its own version numbers, while
213			* packages requiring the original package continue to work with your fork because it replaces the original package.
214			*
215			* This is also useful for packages that contain sub-packages, for example the main symfony/symfony package contains all the Symfony Components which are also
216			* available as individual packages. If you require the main package it will automatically fulfill any requirement of one of the individual components, since it
217			* replaces them.
218			*
219			* Caution is advised when using replace for the sub-package purpose explained above. You should then typically only replace using self.version as a version
220			* constraint, to make sure the main package only replaces the sub-packages of that exact version, and not any other version, which would be incorrect.
221			*
222			* @var array
223			*/
224			public array $replace = [];
225
226			/**
227			* List of other packages that are provided by this package. This is mostly useful for common interfaces. A package could depend on some virtual logger package, any
228			* library that implements this logger interface would simply list it in provide.
229			*
230			* @var array
231			*/
232			public array $provide = [];
233
234			/**
235			* Suggested packages that can enhance or work well with this package. These are informational and are displayed after the package is installed, to give your users a
236			* hint that they could add more packages, even though they are not strictly required.
237			*
238			* The format is like package links above, except that the values are free text and not version constraints.
239			*
240			* @var array
241			*/
242			public array $suggest = [];
243
244			/**
245			* Autoload mapping for a PHP autoloader.
246			*
247			* PSR-4 and PSR-0 autoloading, classmap generation and files includes are supported.
248			*
249			* PSR-4 is the recommended way since it offers greater ease of use (no need to regenerate the autoloader when you add classes).
250			*
251			* @var \ComposerJson\Schemas\AutoloadInterface[]
252			*/
253			public array $autoload = [];
254
255			/**
256			* This section allows to define autoload rules for development purposes.
257			*
258			* Classes needed to run the test suite should not be included in the main autoload rules to avoid polluting the autoloader in production and when other people use
259			* your package as a dependency.
260			*
261			* Therefore, it is a good idea to rely on a dedicated path for your unit tests and to add it within the autoload-dev section.
262			*
263			* @var \ComposerJson\Schemas\AutoloadInterface[]
264			*/
265			public array $autoloadDev = [];
266
267			/**
268			* DEPRECATED: This is only present to support legacy projects, and all new code should preferably use autoloading. As such it is a deprecated practice, but the
269			* feature itself will not likely disappear from Composer.
270			*
271			* A list of paths which should get appended to PHP's include_path.
272			*
273			* @var array
274			*/
275			public array $includePath = [];
276
277			/**
278			* DEPRECATED: This is only present to support legacy PSR-0 style autoloading, and all new code should preferably use PSR-4 without target-dir and projects using
279			* PSR-0 with PHP namespaces are encouraged to migrate to PSR-4 instead.
280			*
281			* Defines the installation target.
282			*
283			* In case the package root is below the namespace declaration you cannot autoload properly. target-dir solves this problem.
284			*
285			* An example is Symfony. There are individual packages for the components. The Yaml component is under Symfony\Component\Yaml. The package root is that Yaml
286			* directory. To make autoloading possible, we need to make sure that it is not installed into vendor/symfony/yaml, but instead into
287			* vendor/symfony/yaml/Symfony/Component/Yaml, so that the autoloader can load it from vendor/symfony/yaml.
288			*
289			* @var string
290			*/
291			public ?string $targetDir;
292
293			/**
294			* This defines the default behavior for filtering packages by stability. This defaults to stable, so if you rely on a dev package, you should specify it in your
295			* file to avoid surprises.
296			*
297			* All versions of each package are checked for stability, and those that are less stable than the minimum-stability setting will be ignored when resolving your
298			* project dependencies. (Note that you can also specify stability requirements on a per-package basis using stability flags in the version constraints that you
299			* specify in a require block (see package links for more details).
300			*
301			* Available options (in order of stability) are dev, alpha, beta, RC, and stable.
302			*
303			* @var string
304			*/
305			public ?string $minimumStability;
306
307			/**
308			* When this is enabled, Composer will prefer more stable packages over unstable ones when finding compatible stable packages is possible. If you require a dev
309			* version or only alphas are available for a package, those will still be selected granted that the minimum-stability allows for it.
310			*
311			* Use "prefer-stable": true to enable.
312			*
313			* @var bool
314			*/
315			public bool $preferStable;
316
317			/**
318			* Custom package repositories to use.
319			*
320			* By default Composer only uses the packagist repository. By specifying repositories you can get packages from elsewhere.
321			*
322			* Repositories are not resolved recursively. You can only add them to your main composer.json. Repository declarations of dependencies' composer.jsons are ignored.
323			*
324			* The following repository types are supported:
325			*
326			* composer: A Composer repository is simply a packages.json file served via the network (HTTP, FTP, SSH), that contains a list of composer.json objects with
327			* additional dist and/or source information. The packages.json file is loaded using a PHP stream. You can set extra options on that stream using the options
328			* parameter. vcs: The version control system repository can fetch packages from git, svn, fossil and hg repositories. pear: With this you can import any pear
329			* repository into your Composer project. package: If you depend on a project that does not have any support for composer whatsoever you can define the package
330			* inline using a package repository. You basically inline the composer.json object.
331			*
332			* @var \ComposerJson\Schemas\Repository[]
333			*/
334			public array $repositories = [];
335
336			/**
337			* A set of configuration options. It is only used for projects. See Config for a description of each individual option.
338			*
339			* @var array
340			*/
341			public array $config = [];
342
343			/**
344			* Composer allows you to hook into various parts of the installation process through the use of scripts.
345			*
346			* See Scripts for events details and examples
347			*
348			* @var array
349			*/
350			public array $scripts = [];
351
352			/**
353			* Arbitrary extra data for consumption by scripts.
354			*
355			* This can be virtually anything. To access it from within a script event handler, you can do:
356			*
357			* $extra = $event->getComposer()->getPackage()->getExtra();
358			*
359			* Optional.
360			*
361			* @var array
362			*/
363			public array $extra = [];
364
365			/**
366			* A set of files that should be treated as binaries and symlinked into the bin-dir (from config).
367			*
368			* See Vendor Binaries for more details.
369			*
370			* Optional.
371			*
372			* @var string\|array
373			*/
374			public $bin;
375
376			/**
377			* A set of options for creating package archives.
378			*
379			* The following options are supported:
380			*
381			* exclude: Allows configuring a list of patterns for excluded paths. The pattern syntax matches .gitignore files. A leading exclamation mark (!) will result in any
382			* matching files to be included even if a previous pattern excluded them. A leading slash will only match at the beginning of the project relative path. An asterisk
383			* will not expand to a directory separator.
384			*
385			* Optional.
386			*
387			* @var array
388			*/
389			public array $archive = [];
390
391			/**
392			* Indicates whether this package has been abandoned.
393			*
394			* It can be boolean or a package name/URL pointing to a recommended alternative.
395			*
396			* Examples:
397			*
398			* Use "abandoned": true to indicates this package is abandoned. Use "abandoned": "monolog/monolog" to indicates this package is abandoned and the recommended
399			* alternative is monolog/monolog.
400			*
401			* Defaults to false.
402			*
403			* Optional.
404			*
405			* @var bool\|string
406			*/
407			public $abandoned;
408
409			/**
410			* A list of regex patterns of branch names that are non-numeric (e.g. "latest" or something), that will NOT be handled as feature branches. This is an array of
411			* strings.
412			*
413			* If you have non-numeric branch names, for example like "latest", "current", "latest-stable" or something, that do not look like a version number, then Composer
414			* handles such branches as feature branches. This means it searches for parent branches, that look like a version or ends at special branches (like master) and the
415			* root package version number becomes the version of the parent branch or at least master or something.
416			*
417			* To handle non-numeric named branches as versions instead of searching for a parent branch with a valid version or special branch name like master, you can set
418			* patterns for branch names, that should be handled as dev version branches.
419			*
420			* This is really helpful when you have dependencies using "self.version", so that not dev-master, but the same branch is installed (in the example: latest-testing).
421			*
422			* Optional.
423			*
424			* @var array
425			*/
426			public array $nonFeatureBranches = [];
427			}
428

EvilFreelancer / composer-json-generator

Issues (12)

Security Analysis no request data

src/Schemas/Composer.php (1 issue)

Labels

Severity

Introduced By

Upgrade to new PHP Analysis Engine

Duplication Side-by-Side

Filter issues like