norm/Gainsight
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

A big commit with a bunch of node modules so I could run puppeteer for Walmart. Added some todos and Headway's templates.

Browse Source
This commit is contained in:
Norm Rasmussen
2024-02-28 17:13:10 -05:00
parent dbcdfc8472
commit 1184fe0cd1
1107 changed files with 76526 additions and 8934 deletions
Download Patch File Download Diff File Expand all files Collapse all files

215
Scripts/node_modules/cosmiconfig/README.md generated vendored
View File

@ -7,7 +7,7 @@ Cosmiconfig searches for and loads configuration for your program.
It features smart defaults based on conventional expectations in the JavaScript ecosystem.
But it's also flexible enough to search wherever you'd like to search, and load whatever you'd like to load.
By default, Cosmiconfig will start where you tell it to start and search up the directory tree for the following:
By default, Cosmiconfig will check the current directory for the following:
- a `package.json` property
- a JSON or YAML, extensionless "rc file"
@ -20,10 +20,11 @@ For example, if your module's name is "myapp", cosmiconfig will search up the di
- a `myapp` property in `package.json`
- a `.myapprc` file in JSON or YAML format
- a `.myapprc.json`, `.myapprc.yaml`, `.myapprc.yml`, `.myapprc.js`, `.myapprc.ts`, `.myapprc.mjs`, or `.myapprc.cjs` file
- a `myapprc`, `myapprc.json`, `myapprc.yaml`, `myapprc.yml`, `myapprc.js`, `myapprc.ts` or `myapprc.cjs` file inside a `.config` subdirectory
- a `myapprc`, `myapprc.json`, `myapprc.yaml`, `myapprc.yml`, `myapprc.js`, `myapprc.ts`, `myapprc.mjs`, or `myapprc.cjs` file inside a `.config` subdirectory
- a `myapp.config.js`, `myapp.config.ts`, `myapp.config.mjs`, or `myapp.config.cjs` file
Cosmiconfig continues to search up the directory tree, checking each of these places in each directory, until it finds some acceptable configuration (or hits the home directory).
Optionally, you can tell it to search up the directory tree using [search strategies],
checking each of these places in each directory, until it finds some acceptable configuration (or hits the home directory).
## Table of contents
@ -45,6 +46,7 @@ Cosmiconfig continues to search up the directory tree, checking each of these pl
- [explorerSync.clearSearchCache()](#explorersyncclearsearchcache)
- [explorerSync.clearCaches()](#explorersyncclearcaches)
- [cosmiconfigOptions](#cosmiconfigoptions)
- [searchStrategy](#searchstrategy)
- [searchPlaces](#searchplaces)
- [loaders](#loaders)
- [packageProp](#packageprop)
@ -56,6 +58,7 @@ Cosmiconfig continues to search up the directory tree, checking each of these pl
- [Caching](#caching)
- [Differences from rc](#differences-from-rc)
- [Usage for end users](#usage-for-end-users)
- [Imports](#imports)
- [Contributing & Development](#contributing--development)
## Installation
@ -93,7 +96,7 @@ explorer.search()
// Load a configuration directly when you know where it should be.
// The result object is the same as for search.
// See documentation for load, below.
explorer.load(pathToConfig).then(..);
explorer.load(pathToConfig).then(/* ... */);
// You can also search and load synchronously.
const explorerSync = cosmiconfigSync(moduleName);
@ -116,7 +119,7 @@ The result object you get from `search` or `load` has the following properties:
```js
const { cosmiconfig } = require('cosmiconfig');
const explorer = cosmiconfig(moduleName[, cosmiconfigOptions])
const explorer = cosmiconfig(moduleName, /* optional */ cosmiconfigOptions)
```
Creates a cosmiconfig instance ("explorer") configured according to the arguments, and initializes its caches.
@ -135,7 +138,7 @@ You may not need them, and should first read about the functions you'll use.
### explorer.search()
```js
explorer.search([searchFrom]).then(result => {..})
explorer.search([searchFrom]).then(result => { /* ... */ })
```
Searches for a configuration file. Returns a Promise that resolves with a [result] or with `null`, if no configuration file is found.
@ -148,13 +151,18 @@ Here's how your default [`search()`] will work:
- Starting from `process.cwd()` (or some other directory defined by the `searchFrom` argument to [`search()`]), look for configuration objects in the following places:
1. A `goldengrahams` property in a `package.json` file.
2. A `.goldengrahamsrc` file with JSON or YAML syntax.
3. A `.goldengrahamsrc.json`, `.goldengrahamsrc.yaml`, `.goldengrahamsrc.yml`, `.goldengrahamsrc.js`, `.goldengrahamsrc.ts`, or `.goldengrahamsrc.cjs` file. (To learn more about how JS files are loaded, see ["Loading JS modules"].)
4. A `goldengrahamsrc`, `goldengrahamsrc.json`, `goldengrahamsrc.yaml`, `goldengrahamsrc.yml`, `goldengrahamsrc.js`, `goldengrahamsrc.ts`, or `goldengrahamsrc.cjs` file in the `.config` subdirectory.
3. A `.goldengrahamsrc.json`, `.goldengrahamsrc.yaml`, `.goldengrahamsrc.yml`, `.goldengrahamsrc.js`, `.goldengrahamsrc.ts`, `.goldengrahamsrc.mjs`, or `.goldengrahamsrc.cjs` file. (To learn more about how JS files are loaded, see ["Loading JS modules"].)
4. A `goldengrahamsrc`, `goldengrahamsrc.json`, `goldengrahamsrc.yaml`, `goldengrahamsrc.yml`, `goldengrahamsrc.js`, `goldengrahamsrc.ts`, `goldengrahamsrc.mjs`, or `goldengrahamsrc.cjs` file in the `.config` subdirectory.
5. A `goldengrahams.config.js`, `goldengrahams.config.ts`, `goldengrahams.config.mjs`, or `goldengrahams.config.cjs` file. (To learn more about how JS files are loaded, see ["Loading JS modules"].)
- If none of those searches reveal a configuration object, move up one directory level and try again.
So the search continues in `./`, `../`, `../../`, `../../../`, etc., checking the same places in each directory.
- Continue searching until arriving at your home directory (or some other directory defined by the cosmiconfig option [`stopDir`]).
- For JS files,
- If none of those searches reveal a configuration object, continue depending on the current search strategy:
- If it's `none` (which is the default if you don't specify a [`stopDir`] option), stop here and return/resolve with `null`.
- If it's `global` (which is the default if you specify a [`stopDir`] option), move up one directory level and try again,
recursing until arriving at the configured [`stopDir`] option, which defaults to the user's home directory.
- After arriving at the [`stopDir`], the global configuration directory (as defined by [`env-paths`] without prefix) is also checked,
looking at the files `config`, `config.json`, `config.yaml`, `config.yml`, `config.js`, `config.ts`, `config.cjs`, and `config.mjs`
in the directory `~/.config/goldengrahams/` (on Linux; see [`env-paths`] documentation for other OSs).
- If it's `project`, check whether a `package.json` file is present in the current directory, and if not,
move up one directory level and try again, recursing until there is one.
- If at any point a parsable configuration is found, the [`search()`] Promise resolves with its [result] \(or, with [`explorerSync.search()`], the [result] is returned).
- If no configuration object is found, the [`search()`] Promise resolves with `null` (or, with [`explorerSync.search()`], `null` is returned).
- If a configuration object is found *but is malformed* (causing a parsing error), the [`search()`] Promise rejects with that error (so you should `.catch()` it). (Or, with [`explorerSync.search()`], the error is thrown.)
@ -178,7 +186,7 @@ If it's a file, the search starts in that file's directory.
### explorer.load()
```js
explorer.load(loadPath).then(result => {..})
explorer.load(loadPath).then(result => { /* ... */ })
```
Loads a configuration file. Returns a Promise that resolves with a [result] or rejects with an error (if the file does not exist or cannot be loaded).
@ -190,6 +198,7 @@ explorer.load('load/this/file.json'); // Tries to load load/this/file.json.
```
If you load a `package.json` file, the result will be derived from whatever property is specified as your [`packageProp`].
`package.yaml` will work as well if you specify these file names in your [`searchPlaces`].
You can do the same thing synchronously with [`explorerSync.load()`].
@ -211,7 +220,7 @@ Performs both [`clearLoadCache()`] and [`clearSearchCache()`].
```js
const { cosmiconfigSync } = require('cosmiconfig');
const explorerSync = cosmiconfigSync(moduleName[, cosmiconfigOptions])
const explorerSync = cosmiconfigSync(moduleName, /* optional */ cosmiconfigOptions)
```
Creates a *synchronous* cosmiconfig instance ("explorerSync") configured according to the arguments, and initializes its caches.
@ -256,6 +265,33 @@ Type: `Object`.
Possible options are documented below.
### searchStrategy
Type: `string`
Default: `global` if [`stopDir`] is specified, `none` otherwise.
The strategy that should be used to determine which directories to check for configuration files.
- `none`: Only checks in the current working directory.
- `project`: Starts in the current working directory, traversing upwards until a `package.{json,yaml}` file is found.
- `global`: Starts in the current working directory, traversing upwards until the configured [`stopDir`]
(or the current user's home directory if none is given). Then, if no configuration is found, also look in the
operating system's default configuration directory (according to [`env-paths`] without prefix),
where a different set of file names is checked:
```js
[
`config`,
`config.json`,
`config.yaml`,
`config.yml`,
`config.js`,
`config.ts`,
`config.cjs`,
`config.mjs`
]
```
### searchPlaces
Type: `Array<string>`.
@ -285,6 +321,7 @@ For the [asynchronous API](#asynchronous-api), these are the default `searchPlac
`.config/${moduleName}rc.yml`,
`.config/${moduleName}rc.js`,
`.config/${moduleName}rc.ts`,
`.config/${moduleName}rc.mjs`,
`.config/${moduleName}rc.cjs`,
`${moduleName}.config.js`,
`${moduleName}.config.ts`,
@ -304,30 +341,41 @@ Read more about [`loaders`] below.
`package.json` is a special value: When it is included in `searchPlaces`, Cosmiconfig will always parse it as JSON and load a property within it, not the whole file.
That property is defined with the [`packageProp`] option, and defaults to your module name.
`package.yaml` (used by pnpm) works the same way.
Examples, with a module named `porgy`:
```js
// Disallow extensions on rc files:
['package.json', '.porgyrc', 'porgy.config.js'][
// Limit the options dramatically:
('package.json', '.porgyrc')
][
// Maybe you want to look for a wide variety of JS flavors:
('porgy.config.js',
['package.json', '.porgyrc', 'porgy.config.js']
```
```js
// Limit the options dramatically:
['package.json', '.porgyrc']
```
```js
// Maybe you want to look for a wide variety of JS flavors:
[
'porgy.config.js',
'porgy.config.mjs',
'porgy.config.ts',
'porgy.config.coffee')
][
// ^^ You will need to designate custom loaders to tell
// Cosmiconfig how to handle `.ts` and `.coffee` files.
'porgy.config.coffee'
]
// ^^ You will need to designate a custom loader to tell
// Cosmiconfig how to handle `.coffee` files.
```
// Look within a .config/ subdirectory of every searched directory:
('package.json',
```js
// Look within a .config/ subdirectory of every searched directory:
[
'package.json',
'.porgyrc',
'.config/.porgyrc',
'.porgyrc.json',
'.config/.porgyrc.json')
];
'.config/.porgyrc.json'
]
```
### loaders
@ -388,24 +436,19 @@ To accomplish that, provide the following `loaders` value:
If you want to load files that are not handled by the loader functions Cosmiconfig exposes, you can write a custom loader function or use one from NPM if it exists.
**Third-party loaders:**
- [cosmiconfig-typescript-loader](https://github.com/codex-/cosmiconfig-typescript-loader)
**Use cases for custom loader function:**
- Allow configuration syntaxes that aren't handled by Cosmiconfig's defaults, like JSON5, INI, or XML.
- Allow ES2015 modules from `.mjs` configuration files.
- Parse JS files with Babel before deriving the configuration.
**Custom loader functions** have the following signature:
```js
```ts
// Sync
(filepath: string, content: string) => Object | null
type SyncLoader = (filepath: string, content: string) => Object | null
// Async
(filepath: string, content: string) => Object | null | Promise<Object | null>
type AsyncLoader = (filepath: string, content: string) => Object | null | Promise<Object | null>
```
Cosmiconfig reads the file when it checks whether the file exists, so it will provide you with both the file's path and its content.
@ -422,24 +465,32 @@ Examples:
```js
// Allow JSON5 syntax:
{
'.json': json5Loader
}
cosmiconfig('foo', {
loaders: {
'.json': json5Loader
}
});
// Allow a special configuration syntax of your own creation:
{
'.special': specialLoader
}
cosmiconfig('foo', {
loaders: {
'.special': specialLoader
}
});
// Allow many flavors of JS, using custom loaders:
{
'.coffee': coffeeScriptLoader
}
cosmiconfig('foo', {
loaders: {
'.coffee': coffeeScriptLoader
}
});
// Allow many flavors of JS but rely on require hooks:
{
'.coffee': defaultLoaders['.js']
}
cosmiconfig('foo', {
loaders: {
'.coffee': defaultLoaders['.js']
}
});
```
### packageProp
@ -447,7 +498,7 @@ Examples:
Type: `string | Array<string>`.
Default: `` `${moduleName}` ``.
Name of the property in `package.json` to look for.
Name of the property in `package.json` (or `package.yaml`) to look for.
Use a period-delimited string or an array of strings to describe a path to nested properties.
@ -456,7 +507,7 @@ For example, the value `'configs.myPackage'` or `['configs', 'myPackage']` will
```json
{
"configs": {
"myPackage": {..}
"myPackage": {"option": "value"}
}
}
```
@ -467,7 +518,7 @@ If nested property names within the path include periods, you need to use an arr
{
"configs": {
"foo.bar": {
"baz": {..}
"baz": {"option": "value"}
}
}
}
@ -575,9 +626,11 @@ package.json
.config/{NAME}rc.yml
.config/{NAME}rc.js
.config/{NAME}rc.ts
.config/{NAME}rc.mjs
.config/{NAME}rc.cjs
{NAME}.config.js
{NAME}.config.ts
{NAME}.config.mjs
{NAME}.config.cjs
```
@ -609,25 +662,30 @@ You can also add a `cosmiconfig` key within your `package.json` file or create o
to configure `cosmiconfig` itself:
```
.config.json
.config.yaml
.config.yml
.config.js
.config.ts
.config.cjs
.config/config.json
.config/config.yaml
.config/config.yml
.config/config.js
.config/config.ts
.config/config.cjs
```
The following property is currently actively supported in these places:
The following properties are currently actively supported in these places:
```yaml
cosmiconfig:
# overrides where configuration files are being searched to enforce a custom naming convention and format
# adds places where configuration files are being searched
searchPlaces:
- .config/{name}.yml
# to enforce a custom naming convention and format, don't merge the above with the tool-defined search places
# (`true` is the default setting)
mergeSearchPlaces: false
```
> **Note:** technically, you can overwrite all options described in [cosmiconfigOptions](#cosmiconfigoptions) here,
> but everything not listed above should be used at your own risk, as it has not been tested explicitly.
> The only exceptions to this are the `loaders` property, which is explicitly not supported at this time,
> and the `searchStrategy` property, which is intentionally disallowed.
You can also add more root properties outside the `cosmiconfig` property
to configure your tools, entirely eliminating the need to look for additional configuration files:
@ -640,6 +698,41 @@ prettier:
semi: true
```
### Imports
Wherever you put your configuration (the package.json file, a root config file or a package-specific config file),
you can use the special `$import` key to import another file as a base.
For example, you can import from an npm package (in this example, `@foocorp/config`).
`.prettierrc.base.yml` in said npm package could define some company-wide defaults:
```yaml
printWidth: 120
semi: true
tabWidth: 2
```
And then, the `.prettierrc.yml` file in the project itself would just reference that file,
optionally overriding the defaults with project-specific settings:
```yaml
$import: node_modules/@foocorp/config/.prettierrc.base.yml
# we want more space!
printWidth: 200
```
It is possible to import multiple base files by specifying an array of paths,
which will be processed in declaration order;
that means that the last entry will win if there are conflicting properties.
It is also possible to import file formats other than the importing format
as long as they are supported by the loaders specified by the developer of the tool you're configuring.
```yaml
$import: [first.yml, second.json, third.config.js]
```
## Contributing & Development
Please note that this project is released with a [Contributor Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
@ -683,3 +776,7 @@ And please do participate!
[`explorer.load()`]: #explorerload
["Loading JS modules"]: #loading-js-modules
[`env-paths`]: https://github.com/sindresorhus/env-paths
[search strategies]: #searchstrategy