-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdefault-config.jsonc
221 lines (196 loc) · 8.74 KB
/
default-config.jsonc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
{
// Path to the file where the report will be published
"outputFile": "./license-details.xlsx",
/*
* Contains information over the types of licenses the user wishes to permit
* with in their project.
*/
"license": {
/*
* Your profile dictates the basic types of licenses that the user would wish to
* permit. Profiles are defined within profiles.jsonc
*/
"profile": "Most Permissive",
/*
* One can define an additional white list of licences that they wish to allow
* even if said license type is not a part of the profile.
*/
"whiteList": [],
/*
* A list of packages for which you wish to make an explicit exception to the white
* lists you have defined. Each element in this list should be in the form
* package/license. For example having jszip/GPL-3.0 as an item will mean that
* for jszip and ONLY jszip, you are willing to accept the GPL-3.0 license.
*/
"exceptions": [],
/*
* Unfortunately, not all licenses are contained within a nice LICENSE.TXT file. In
* this case, you can supply what ever license information you've (manually, for the time being),
* managed to scrape from the license file (where ever she be found). If populated, this list will
* be a list of lists. An entry in the list would be like ["path/to/LICENSE-DOC", ["LIC1", "LIC2"]]
* where LIC1 and LIC2 are types of licenses like MIT or Apache 2.0.
*/
"alternateLocations": []
},
/*
* Since many projects may place stricter requirements on utilising software that does
* cryptography, pack-it-in allows for these packages to be treated with extra scrutiny.
*
* By default, this feature is disabled but when enabled, checking cryptography related
* packages will be an extra part of the verification pipeline.
*/
"cryptography": {
// Straightforward: This is whether cryptography checking is enabled
"enable": false,
// A list of packages which do infact contain encryption related functionality
// but are deemed by your team to be safe.
"packageList": [],
// These are packages which have crypt in the name or description but, in fact,
// contain no crtptography related functionality.
"exceptions": []
},
// Whether or not we analyse NPM and the other build tools used for the project
// Typically you'd like this set to false.
"analyseBuildTools": false,
/*
* Defines the directories where package.json files are able to be found.
* By default, pack-it-in will only check the directory in which it is run but,
* one can change the parent directory to either be a relative or absolute path.
*
* It is also possible, for larger projects, to specify multiple locations to perform
* verification. This could be useful in cases where you have a full-stack application
* where 3rd party components for the front end and backend are found in different locations.
*/
"targetDirectories": [
{
// Name of the project....
"name": "My Project",
// Location of the package.json
"parentDirectory": ".",
/*
* This controlls whether or not the target can be thought of as a project in its' own right.
* An example of when something may not be a project is when analysing the software used by
* NPM and other build tools (which pack-it-in does by default).
*/
"isProject": true,
/*
* This is set to true if the package provided has a package.json to consult.
* While for most modern stacks, this will always be set to true, the developers
* of pack-it-in are all too familiar of working with stacks that do not utilise
* the latest and greatest.
*
* As a result, if set to false, one can define an alternate JSON file where license information
* for a project can be defined. It will be up to the user to compile this
* information on a case by case basis.
*
* If set to false and no additional package is provided, pack-it-in will simply ignore
* the project.
*/
"hasPackage": true,
/*
* The self defined JSON (referenced above) can also include dependency information for non JS projects
* that you wish to have included within the Pack-Spec document.
*
* In these cases, the user defined JSON will be read but no attempts will be made to conduct a further
* exploration of the file system. Set to fa
*
* This option will only be consulted if "hasPackage" is set to false AND a user supplied package.json is
* given. Set this option to true if the user-supplied package.json includes non JS modules.
*/
"includesNonJSModules": false,
// In the case where no package.json is defined, and the user is instead using a custom-defined
// package.json, this will allow the user to decide (on the scale of the subproject) whether modules
// belonging to the project are to be treated as dev dependencies or not.
"isDev": true,
/*
* If you wish to have a user defined file where you detail
* information about a package's dependencies you can replace
* this false with a path-string to the JSON file you have dependency
* information within.
*
* If you do not have user defiened dependency information, you can
* simply leave this field out. The programme will understand.
*
* (JK. It will silently judge you. The way all computers do...)
*
* Should you choose to have a user defined dependency file, the file should be structured
* like so:
*
* {
* "dependencies":
* [
* ["dependencyOne", {
* // Any information can go here
* }],
* ["dependencyTwo", {
* // Any information can go here
* }],
* etc. etc. etc.
* ]
* }
*/
"userDefinedDependency": false,
/*
* In addition to being able to isolate specific packages, one can also ignore "devDependencies" on a sub-project
* by sub-project basis. If this is the case, the second excel sheet will not contain any of the devDependencies
* within said project.
*/
"ignoreDevDependencies": false,
// List of packages to ignore within a given project.
"ignore": []
}
],
/*
* Defines the fields to be included within the report.
*
* These objects consist of two fields:
* "columnTitle" - The title of the column
*
* The second field is one of:
* "variableValue" - The field of license information we wish to list
* "defaultValue" (Not showcased here) A constant value that is filled for every software.
* You may wish to do something like
* {
* "columnTitle": "Approver",
* "defaultValue": "Mark Simms"
* }
*
* To list yourself as the person who "signs off" on a software's suitability
* for inclusion.
*
*/
"reportFields": [
{
"columnTitle": "Software Name/Version",
"variableValue": "nameVersion"
},
{
"columnTitle": "Description",
"variableValue": "description"
},
{
"columnTitle": "License and Version",
"variableValue": "preferredLicense"
},
{
"columnTitle": "Additional Licenses",
"variableValue": "aditionalLicense"
},
{
"columnTitle": "Software/License Location",
"variableValue": "homepage"
},
{
"columnTitle": "Author",
"variableValue": "authorName"
}
],
// Directories to ignore in the file systgem crawl.
"ignoreDirectories": [".bin", ".cache"],
/*
* List of packages we wish to analyse the dependencies of but to exclude from the pack-spec document.
* You may wish to use this feature if there is first party software that is picked up by the scan but,
* don't want it included in the report
*/
"excludeFromPackSpec": []
}