Skip to content

Commit 225a84a

Browse files
mscharleymscharley
committed
feat: initial rush init
0 parents  commit 225a84a

11 files changed

+994
-0
lines changed

‎.gitattributes

+14
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
# Don't allow people to merge changes to these generated files, because the result
2+
# may be invalid. You need to run "rush update" again.
3+
pnpm-lock.yaml merge=binary
4+
shrinkwrap.yaml merge=binary
5+
npm-shrinkwrap.json merge=binary
6+
yarn.lock merge=binary
7+
8+
# Rush's JSON config files use JavaScript-style code comments. The rule below prevents pedantic
9+
# syntax highlighters such as GitHub's from highlighting these comments as errors. Your text editor
10+
# may also require a special configuration to allow comments in JSON.
11+
#
12+
# For more information, see this issue: https://github.com/microsoft/rushstack/issues/1088
13+
#
14+
*.json linguist-language=JSON-with-Comments

‎.gitignore

+63
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
# Logs
2+
*.log
3+
npm-debug.log*
4+
yarn-debug.log*
5+
yarn-error.log*
6+
7+
# Runtime data
8+
*.pid
9+
*.seed
10+
*.pid.lock
11+
12+
# Directory for instrumented libs generated by jscoverage/JSCover
13+
lib-cov
14+
15+
# Coverage directory used by tools like istanbul
16+
coverage
17+
18+
# nyc test coverage
19+
.nyc_output
20+
21+
# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
22+
.grunt
23+
24+
# Bower dependency directory (https://bower.io/)
25+
bower_components
26+
27+
# node-waf configuration
28+
.lock-wscript
29+
30+
# Compiled binary addons (https://nodejs.org/api/addons.html)
31+
build/Release
32+
33+
# Dependency directories
34+
node_modules/
35+
jspm_packages/
36+
37+
# Optional npm cache directory
38+
.npm
39+
40+
# Optional eslint cache
41+
.eslintcache
42+
43+
# Optional REPL history
44+
.node_repl_history
45+
46+
# Output of 'npm pack'
47+
*.tgz
48+
49+
# Yarn Integrity file
50+
.yarn-integrity
51+
52+
# dotenv environment variables file
53+
.env
54+
55+
# next.js build output
56+
.next
57+
58+
# OS X temporary files
59+
.DS_Store
60+
61+
# Rush temporary files
62+
common/temp/
63+
**/.rush/temp/

‎.travis.yml

+18
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
language: node_js
2+
node_js:
3+
- '8.9.4'
4+
script:
5+
- set -e
6+
7+
- echo 'Checking for missing change logs...' && echo -en 'travis_fold:start:change\\r'
8+
- git fetch origin master:refs/remotes/origin/master -a
9+
- node common/scripts/install-run-rush.js change -v
10+
- echo -en 'travis_fold:end:change\\r'
11+
12+
- echo 'Installing...' && echo -en 'travis_fold:start:install\\r'
13+
- node common/scripts/install-run-rush.js install
14+
- echo -en 'travis_fold:end:install\\r'
15+
16+
- echo 'Building...' && echo -en 'travis_fold:start:build\\r'
17+
- node common/scripts/install-run-rush.js rebuild --verbose
18+
- echo -en 'travis_fold:end:build\\r'

‎.vscode/settings.json

+5
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
{
2+
"files.associations": {
3+
"*.json": "jsonc"
4+
}
5+
}

‎common/config/rush/.npmrc

+12
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
# Rush uses this file to configure the package registry, regardless of whether the
2+
# package manager is PNPM, NPM, or Yarn. Prior to invoking the package manager,
3+
# Rush will always copy this file to the folder where installation is performed.
4+
# When NPM is the package manager, Rush works around NPM's processing of
5+
# undefined environment variables by deleting any lines that reference undefined
6+
# environment variables.
7+
#
8+
# DO NOT SPECIFY AUTHENTICATION CREDENTIALS IN THIS FILE. It should only be used
9+
# to configure registry sources.
10+
11+
registry=https://registry.npmjs.org/
12+
always-auth=false

‎common/config/rush/command-line.json

+256
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,256 @@
1+
/**
2+
* This configuration file defines custom commands for the "rush" command-line.
3+
* For full documentation, please see https://rushjs.io
4+
*/
5+
{
6+
"$schema": "https://developer.microsoft.com/json-schemas/rush/v5/command-line.schema.json",
7+
8+
/**
9+
* Custom "commands" introduce new verbs for the command-line. To see the help for these
10+
* example commands, try "rush --help", "rush my-bulk-command --help", or
11+
* "rush my-global-command --help".
12+
*/
13+
"commands": [
14+
// {
15+
// /**
16+
// * (Required) Determines the type of custom command.
17+
// * Rush's "bulk" commands are invoked separately for each project. Rush will look in
18+
// * each project's package.json file for a "scripts" entry whose name matches the
19+
// * command name. By default, the command will run for every project in the repo,
20+
// * according to the dependency graph (similar to how "rush build" works).
21+
// * The set of projects can be restricted e.g. using the "--to" or "--from" parameters.
22+
// */
23+
// "commandKind": "bulk",
24+
//
25+
// /**
26+
// * (Required) The name that will be typed as part of the command line. This is also the name
27+
// * of the "scripts" hook in the project's package.json file.
28+
// * The name should be comprised of lower case words separated by hyphens or colons. The name should include an
29+
// * English verb (e.g. "deploy"). Use a hyphen to separate words (e.g. "upload-docs"). A group of related commands
30+
// * can be prefixed with a colon (e.g. "docs:generate", "docs:deploy", "docs:serve", etc).
31+
// *
32+
// * Note that if the "rebuild" command is overridden here, it becomes separated from the "build" command
33+
// * and will call the "rebuild" script instead of the "build" script.
34+
// */
35+
// "name": "my-bulk-command",
36+
//
37+
// /**
38+
// * (Required) A short summary of the custom command to be shown when printing command line
39+
// * help, e.g. "rush --help".
40+
// */
41+
// "summary": "Example bulk custom command",
42+
//
43+
// /**
44+
// * A detailed description of the command to be shown when printing command line
45+
// * help (e.g. "rush --help my-command").
46+
// * If omitted, the "summary" text will be shown instead.
47+
// *
48+
// * Whenever you introduce commands/parameters, taking a little time to write meaningful
49+
// * documentation can make a big difference for the developer experience in your repo.
50+
// */
51+
// "description": "This is an example custom command that runs separately for each project",
52+
//
53+
// /**
54+
// * By default, Rush operations acquire a lock file which prevents multiple commands from executing simultaneously
55+
// * in the same repo folder. (For example, it would be a mistake to run "rush install" and "rush build" at the
56+
// * same time.) If your command makes sense to run concurrently with other operations,
57+
// * set "safeForSimultaneousRushProcesses" to true to disable this protection.
58+
// *
59+
// * In particular, this is needed for custom scripts that invoke other Rush commands.
60+
// */
61+
// "safeForSimultaneousRushProcesses": false,
62+
//
63+
// /**
64+
// * (Required) If true, then this command is safe to be run in parallel, i.e. executed
65+
// * simultaneously for multiple projects. Similar to "rush build", regardless of parallelism
66+
// * projects will not start processing until their dependencies have completed processing.
67+
// */
68+
// "enableParallelism": false,
69+
//
70+
// /**
71+
// * Normally projects will be processed according to their dependency order: a given project will not start
72+
// * processing the command until all of its dependencies have completed. This restriction doesn't apply for
73+
// * certain operations, for example a "clean" task that deletes output files. In this case
74+
// * you can set "ignoreDependencyOrder" to true to increase parallelism.
75+
// */
76+
// "ignoreDependencyOrder": false,
77+
//
78+
// /**
79+
// * Normally Rush requires that each project's package.json has a "scripts" entry matching
80+
// * the custom command name. To disable this check, set "ignoreMissingScript" to true;
81+
// * projects with a missing definition will be skipped.
82+
// */
83+
// "ignoreMissingScript": false,
84+
//
85+
// /**
86+
// * When invoking shell scripts, Rush uses a heuristic to distinguish errors from warnings:
87+
// * - If the shell script returns a nonzero process exit code, Rush interprets this as "one or more errors".
88+
// * Error output is displayed in red, and it prevents Rush from attempting to process any downstream projects.
89+
// * - If the shell script returns a zero process exit code but writes something to its stderr stream,
90+
// * Rush interprets this as "one or more warnings". Warning output is printed in yellow, but does NOT prevent
91+
// * Rush from processing downstream projects.
92+
// *
93+
// * Thus, warnings do not interfere with local development, but they will cause a CI job to fail, because
94+
// * the Rush process itself returns a nonzero exit code if there are any warnings or errors. This is by design.
95+
// * In an active monorepo, we've found that if you allow any warnings in your master branch, it inadvertently
96+
// * teaches developers to ignore warnings, which quickly leads to a situation where so many "expected" warnings
97+
// * have accumulated that warnings no longer serve any useful purpose.
98+
// *
99+
// * Sometimes a poorly behaved task will write output to stderr even though its operation was successful.
100+
// * In that case, it's strongly recommended to fix the task. However, as a workaround you can set
101+
// * allowWarningsInSuccessfulBuild=true, which causes Rush to return a nonzero exit code for errors only.
102+
// *
103+
// * Note: The default value is false. In Rush 5.7.x and earlier, the default value was true.
104+
// */
105+
// "allowWarningsInSuccessfulBuild": false
106+
// },
107+
//
108+
// {
109+
// /**
110+
// * (Required) Determines the type of custom command.
111+
// * Rush's "global" commands are invoked once for the entire repo.
112+
// */
113+
// "commandKind": "global",
114+
//
115+
// "name": "my-global-command",
116+
// "summary": "Example global custom command",
117+
// "description": "This is an example custom command that runs once for the entire repo",
118+
//
119+
// "safeForSimultaneousRushProcesses": false,
120+
//
121+
// /**
122+
// * A script that will be invoked using the OS shell. The working directory will be the folder
123+
// * that contains rush.json. If custom parameters are associated with this command, their
124+
// * values will be appended to the end of this string.
125+
// */
126+
// "shellCommand": "node common/scripts/my-global-command.js"
127+
// }
128+
],
129+
130+
/**
131+
* Custom "parameters" introduce new parameters for specified Rush command-line commands.
132+
* For example, you might define a "--production" parameter for the "rush build" command.
133+
*/
134+
"parameters": [
135+
// {
136+
// /**
137+
// * (Required) Determines the type of custom parameter.
138+
// * A "flag" is a custom command-line parameter whose presence acts as an on/off switch.
139+
// */
140+
// "parameterKind": "flag",
141+
//
142+
// /**
143+
// * (Required) The long name of the parameter. It must be lower-case and use dash delimiters.
144+
// */
145+
// "longName": "--my-flag",
146+
//
147+
// /**
148+
// * An optional alternative short name for the parameter. It must be a dash followed by a single
149+
// * lower-case or upper-case letter, which is case-sensitive.
150+
// *
151+
// * NOTE: The Rush developers recommend that automation scripts should always use the long name
152+
// * to improve readability. The short name is only intended as a convenience for humans.
153+
// * The alphabet letters run out quickly, and are difficult to memorize, so *only* use
154+
// * a short name if you expect the parameter to be needed very often in everyday operations.
155+
// */
156+
// "shortName": "-m",
157+
//
158+
// /**
159+
// * (Required) A long description to be shown in the command-line help.
160+
// *
161+
// * Whenever you introduce commands/parameters, taking a little time to write meaningful
162+
// * documentation can make a big difference for the developer experience in your repo.
163+
// */
164+
// "description": "A custom flag parameter that is passed to the scripts that are invoked when building projects",
165+
//
166+
// /**
167+
// * (Required) A list of custom commands and/or built-in Rush commands that this parameter may
168+
// * be used with. The parameter will be appended to the shell command that Rush invokes.
169+
// */
170+
// "associatedCommands": [ "build", "rebuild" ]
171+
// },
172+
//
173+
// {
174+
// /**
175+
// * (Required) Determines the type of custom parameter.
176+
// * A "string" is a custom command-line parameter whose value is a simple text string.
177+
// */
178+
// "parameterKind": "string",
179+
// "longName": "--my-string",
180+
// "description": "A custom string parameter for the \"my-global-command\" custom command",
181+
//
182+
// "associatedCommands": [ "my-global-command" ],
183+
//
184+
// /**
185+
// * The name of the argument, which will be shown in the command-line help.
186+
// *
187+
// * For example, if the parameter name is '--count" and the argument name is "NUMBER",
188+
// * then the command-line help would display "--count NUMBER". The argument name must
189+
// * be comprised of upper-case letters, numbers, and underscores. It should be kept short.
190+
// */
191+
// "argumentName": "SOME_TEXT",
192+
//
193+
// /**
194+
// * If true, this parameter must be included with the command. The default is false.
195+
// */
196+
// "required": false
197+
// },
198+
//
199+
// {
200+
// /**
201+
// * (Required) Determines the type of custom parameter.
202+
// * A "choice" is a custom command-line parameter whose argument must be chosen from a list of
203+
// * allowable alternatives.
204+
// */
205+
// "parameterKind": "choice",
206+
// "longName": "--my-choice",
207+
// "description": "A custom choice parameter for the \"my-global-command\" custom command",
208+
//
209+
// "associatedCommands": [ "my-global-command" ],
210+
//
211+
// /**
212+
// * If true, this parameter must be included with the command. The default is false.
213+
// */
214+
// "required": false,
215+
//
216+
// /**
217+
// * Normally if a parameter is omitted from the command line, it will not be passed
218+
// * to the shell command. this value will be inserted by default. Whereas if a "defaultValue"
219+
// * is defined, the parameter will always be passed to the shell command, and will use the
220+
// * default value if unspecified. The value must be one of the defined alternatives.
221+
// */
222+
// "defaultValue": "vanilla",
223+
//
224+
// /**
225+
// * (Required) A list of alternative argument values that can be chosen for this parameter.
226+
// */
227+
// "alternatives": [
228+
// {
229+
// /**
230+
// * A token that is one of the alternatives that can be used with the choice parameter,
231+
// * e.g. "vanilla" in "--flavor vanilla".
232+
// */
233+
// "name": "vanilla",
234+
//
235+
// /**
236+
// * A detailed description for the alternative that can be shown in the command-line help.
237+
// *
238+
// * Whenever you introduce commands/parameters, taking a little time to write meaningful
239+
// * documentation can make a big difference for the developer experience in your repo.
240+
// */
241+
// "description": "Use the vanilla flavor (the default)"
242+
// },
243+
//
244+
// {
245+
// "name": "chocolate",
246+
// "description": "Use the chocolate flavor"
247+
// },
248+
//
249+
// {
250+
// "name": "strawberry",
251+
// "description": "Use the strawberry flavor"
252+
// }
253+
// ]
254+
// }
255+
]
256+
}

0 commit comments

Comments
 (0)