Node js config js: GitHub - lorenwest/node-config: Node.js Application Configuration

Содержание

Начало работы · Jest

Установите Jest с помощью yarn:

Или npm:

Примечание: документация Jest использует команды yarn, но npm также будет работать. Вы можете сравнить команды yarn и npm в документации yarn, здесь.

Для начала напишем тест для функции, которая складывает два числа. Во-первых создайте файл sum.js:

Затем создайте файл с именем sum.test.js. Он будет содержать сам тест:

Добавьте следующий раздел в package.json:

Наконец, запустите yarn test или npm run test и Jest выведет это сообщение:

Вы только что успешно написали первый тест с использованием Jest!

Данный тест использует expect и toBe для проверки идентичности двух данных значений. Чтобы узнать об остальных вещах, которые можно протестировать с использованием Jest, смотрите использование сопоставлений.

Запуск из командной строки#

Вы можете запустить Jest прямо из командной строки (если он глобально доступен в PATH, например yarn global add jest или npm install jest --global) с множеством полезных опций.

Вот так можно запустить Jest для проверки файлов совпадающих с my-test, используя config.json в качестве файла конфигурации и для отображения нативного уведомления ОС после завершения:

Если вы хотите узнать больше о работе с jest в командной строке, обратите внимание на страницу параметров командной строки Jest.

Дополнительная конфигурация#

Создание базового файла конфигурации#

Исходя из ваших нужд, Jest задаст вам несколько вопросов и создаст базовый файл конфигурации с кратким описанием для каждой опции:

С использованием Babel#

Для использования Babel, установите необходимые зависимости через yarn:

Настройте Babel на вашу текущую версию Node Js, создав файл babel. config.js в корне вашего проекта:

Идеальная конфигурация для Babel будет зависеть от вашего проекта. Смотрите документацию Babel для получения дополнительной информации.

**Добавление отдельной конфигурации для Babel только на время запуска Jest**

Jest автоматически установит для process.env.NODE_ENV значение 'test' если не указано другое. Вы можете использовать эту опцию, чтобы добавить настройки, которые будут использоваться только во время запуска Jest, например:

Примечание: babel-jest автоматически устанавливается при установке Jest и преобразует файлы если в вашем проекте есть существующая конфигурация babel. Для обхода данного поведения, вы можете явно сбросить опцию transform в конфигурации:

**Поддержка Babel 6**

В 24-й версии Jest прекратил поддерживать Babel 6. Мы настоятельно рекомендуем вам обновиться до Babel 7, который активно поддерживается. Однако, если вы не можете перейти на Babel 7, то либо используйте Jest 23, либо обновитесь до Jest 24 вручную заблокировав babel-jest на 23-й версии, как показано ниже:

Хотя мы обычно рекомендуем использовать одну и ту же версию каждого пакета Jest, данное решение позволит вам продолжить использовать последнюю версию Jest с Babel 6.

С использованием Webpack#

Jest может использоваться в проектах, использующих webpack для управления ресурсами, стилями и компиляцией. Webpack действительно привносит некоторые особенности, способные создать проблемы программистам, в сравнении с другими инструментами. Обратитесь к разделу руководство по работе с Webpack для начала работы с ним.

С использованием Parcel#

Jest может использоваться в проектах, использующих parcel-bundler для управления изображениями, стилями и компиляцией аналогично webpack Parcel не требует настройки Обратитесь к официальной документации.

С использованием TypeScript#

Jest поддерживает TypeScript, через Babel. Сначала убедитесь, что вы следовали инструкциям по настройке Babel выше. Далее установите @babel/preset-typescript через yarn:

Затем добавьте @babel/preset-typescript в список пресетов в ваш babel.config.js.

Однако, есть несколько подводных камней в использовании TypeScript вместе с Babel. Поскольку TypeScript поддерживается в Babel через транспиляцию, Jest не будет проверять типы ваших тестах когда они запущены. Если вы хотите, то вы можете использовать ts-jest взамен, или просто запустите компилятор TypeScript tsc отдельно (или как часть вашего процесса сборки).

Вы также можете установить модуль @types/jest для версии Jest которую вы используете. Это поможет обеспечить полный набор текста при написании ваших тестов с TypeScript.

Для модулей @types/* рекомендуется сопоставлять версию Jest с версией связанного модуля. Например, если вы используете 26.4.0 версию jest , то использование 26.4.x из @types/jest является идеальным. В целом, старайтесь максимально приблизить основную (26) и минорную (4) версию.

Configuring Jest · Jest

Jest’s configuration can be defined in the package.json file of your project, or through a jest.config.js, or jest.config.ts file or through the --config <path/to/file.js|ts|cjs|mjs|json> option. If you’d like to use your package.json to store Jest’s config, the "jest" key should be used on the top level so Jest will know how to find your settings:

Or through JavaScript:

Or through TypeScript (if ts-node is installed):

Please keep in mind that the resulting configuration must be JSON-serializable.

When using the --config option, the JSON file must not contain a «jest» key:

Options#

These options let you control Jest’s behavior in your package. json file. The Jest philosophy is to work great by default, but sometimes you just need more configuration power.

Defaults#

You can retrieve Jest’s default options to expand them if needed:

Reference#

automock [boolean]#

Default: false

This option tells Jest that all imported modules in your tests should be mocked automatically. All modules used in your tests will have a replacement implementation, keeping the API surface.

Example:

Note: Node modules are automatically mocked when you have a manual mock in place (e.g.: __mocks__/lodash.js). More info here.

Note: Core modules, like fs, are not mocked by default. They can be mocked explicitly, like jest.mock('fs').

bail [number | boolean]#

Default: 0

By default, Jest runs all tests and produces all errors into the console upon completion. The bail config option can be used here to have Jest stop running tests after n failures. Setting bail to true is the same as setting bail to 1.

cacheDirectory [string]#

Default: "/tmp/<path>"

The directory where Jest should store its cached dependency information.

Jest attempts to scan your dependency tree once (up-front) and cache it in order to ease some of the filesystem raking that needs to happen while running tests. This config option lets you customize where Jest stores that cache data on disk.

clearMocks [boolean]#

Default: false

Automatically clear mock calls and instances before every test. Equivalent to calling jest.clearAllMocks() before each test. This does not remove any mock implementation that may have been provided.

collectCoverage [boolean]#

Default: false

Indicates whether the coverage information should be collected while executing the test. Because this retrofits all executed files with coverage collection statements, it may significantly slow down your tests.

collectCoverageFrom [array]#

Default: undefined

An array of glob patterns indicating a set of files for which coverage information should be collected. If a file matches the specified glob pattern, coverage information will be collected for it even if no tests exist for this file and it’s never required in the test suite.

Example:

This will collect coverage information for all the files inside the project’s rootDir, except the ones that match **/node_modules/** or **/vendor/**.

Note: This option requires collectCoverage to be set to true or Jest to be invoked with --coverage.

Help:If you are seeing coverage output such as…

Most likely your glob patterns are not matching any files. Refer to the micromatch documentation to ensure your globs are compatible.

coverageDirectory [string]#

Default: undefined

The directory where Jest should output its coverage files.

coveragePathIgnorePatterns [array<string>]#

Default: ["/node_modules/"]

An array of regexp pattern strings that are matched against all file paths before executing the test. If the file path matches any of the patterns, coverage information will be skipped.

These pattern strings match against the full path. Use the <rootDir> string token to include the path to your project’s root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: ["<rootDir>/build/", "<rootDir>/node_modules/"].

coverageProvider [string]#

Indicates which provider should be used to instrument code for coverage. Allowed values are babel (default) or v8.

Note that using v8 is considered experimental. This uses V8’s builtin code coverage rather than one based on Babel. It is not as well tested, and it has also improved in the last few releases of Node. Using the latest versions of node (v14 at the time of this writing) will yield better results.

coverageReporters [array<string | [string, options]>]#

Default: ["json", "lcov", "text", "clover"]

A list of reporter names that Jest uses when writing coverage reports. Any istanbul reporter can be used.

Note: Setting this option overwrites the default values. Add "text" or "text-summary" to see a coverage summary in the console output.

Note: You can pass additional options to the istanbul reporter using the tuple form. Например:

For the additional information about the options object shape you can refer to CoverageReporterWithOptions type in the type definitions.

coverageThreshold [object]#

Default: undefined

This will be used to configure minimum threshold enforcement for coverage results. Thresholds can be specified as global, as a glob, and as a directory or file path. If thresholds aren’t met, jest will fail. Thresholds specified as a positive number are taken to be the minimum percentage required. Thresholds specified as a negative number represent the maximum number of uncovered entities allowed.

For example, with the following configuration jest will fail if there is less than 80% branch, line, and function coverage, or if there are more than 10 uncovered statements:

If globs or paths are specified alongside global, coverage data for matching paths will be subtracted from overall coverage and thresholds will be applied independently. Thresholds for globs are applied to all files matching the glob. If the file specified by path is not found, an error is returned.

For example, with the following configuration:

Jest will fail if:

The ./src/components directory has less than 40% branch or statement coverage.
One of the files matching the ./src/reducers/**/*.js glob has less than 90% statement coverage.
The ./src/api/very-important-module.js file has less than 100% coverage.
Every remaining file combined has less than 50% coverage (global).

dependencyExtractor [string]#

Default: undefined

This option allows the use of a custom dependency extractor. It must be a node module that exports an object with an extract function. E.g.:

The extract function should return an iterable (Array, Set, etc.) with the dependencies found in the code.

That module can also contain a getCacheKey function to generate a cache key to determine if the logic has changed and any cached artifacts relying on it should be discarded.

displayName [string, object]#

default: undefined

Allows for a label to be printed alongside a test while it is running. This becomes more useful in multi-project repositories where there can be many jest configuration files. This visually tells which project a test belongs to. Here are sample valid values.

As a secondary option, an object with the properties name and color can be passed. This allows for a custom configuration of the background color of the displayName. displayName defaults to white when its value is a string. Jest uses chalk to provide the color. As such, all of the valid options for colors supported by chalk are also supported by jest.

errorOnDeprecated [boolean]#

Default: false

Make calling deprecated APIs throw helpful error messages. Useful for easing the upgrade process.

extraGlobals [array<string>]#

Default: undefined

Test files run inside a vm, which slows calls to global context properties (e.g. Math). With this option you can specify extra properties to be defined inside the vm for faster lookups.

For example, if your tests call Math often, you can pass it by setting extraGlobals.

forceCoverageMatch [array<string>]#

Default: ['']

Test files are normally ignored from collecting code coverage. With this option, you can overwrite this behavior and include otherwise ignored files in code coverage.

For example, if you have tests in source files named with .t.js extension as following:

You can collect coverage from those files with setting forceCoverageMatch.

globals [object]#

Default: {}

A set of global variables that need to be available in all test environments.

For example, the following would create a global __DEV__ variable set to true in all test environments:

Note that, if you specify a global reference value (like an object or array) here, and some code mutates that value in the midst of running a test, that mutation will not be persisted across test runs for other test files. In addition, the globals object must be json-serializable, so it can’t be used to specify global functions. For that, you should use setupFiles.

globalSetup [string]#

Default: undefined

This option allows the use of a custom global setup module which exports an async function that is triggered once before all test suites. This function gets Jest’s globalConfig object as a parameter.

Note: A global setup module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.

Note: Any global variables that are defined through globalSetup can only be read in globalTeardown. You cannot retrieve globals defined here in your test suites.

Note: While code transformation is applied to the linked setup-file, Jest will not transform any code in node_modules. This is due to the need to load the actual transformers (e.g. babel or typescript) to perform transformation.

Example:

globalTeardown [string]#

Default: undefined

This option allows the use of a custom global teardown module which exports an async function that is triggered once after all test suites. This function gets Jest’s globalConfig object as a parameter.

Note: A global teardown module configured in a project (using multi-project runner) will be triggered only when you run at least one test from this project.

Note: The same caveat concerning transformation of node_modules as for globalSetup applies to globalTeardown.

haste [object]#

Default: undefined

This will be used to configure the behavior of jest-haste-map, Jest’s internal file crawler/cache system. The following options are supported:

injectGlobals [boolean]#

Default: true

Insert Jest’s globals (expect, test, describe, beforeEach etc.) into the global environment. If you set this to false, you should import from @jest/globals, e.g.

Note: This option is only supported using jest-circus.

maxConcurrency [number]#

Default: 5

A number limiting the number of tests that are allowed to run at the same time when using test.concurrent. $ it may cause hard to spot errors. E.g. relay will replace all modules which contain relay as a substring in its name: relay, react-relay and graphql-relay will all be pointed to your stub.

modulePathIgnorePatterns [array<string>]#

Default: []

An array of regexp pattern strings that are matched against all module paths before those paths are to be considered ‘visible’ to the module loader. If a given module’s path matches any of the patterns, it will not be require()-able in the test environment.

modulePaths [array<string>]#

Default: []

An alternative API to setting the NODE_PATH env variable, modulePaths is an array of absolute paths to additional locations to search when resolving modules. Use the <rootDir> string token to include the path to your project’s root directory. Example: ["<rootDir>/app/"].

notify [boolean]#

Default: false

Activates notifications for test results.

Beware: Jest uses node-notifier to display desktop notifications. On Windows, it creates a new start menu entry on the first use and not display the notification. Notifications will be properly displayed on subsequent runs

notifyMode [string]#

Default: failure-change

Specifies notification mode. Requires notify: true.

Modes#

always: always send a notification.
failure: send a notification when tests fail.
success: send a notification when tests pass.
change: send a notification when the status changed.
success-change: send a notification when tests pass or once when it fails.
failure-change: send a notification when tests fail or once when it passes.

preset [string]#

Default: undefined

A preset that is used as a base for Jest’s configuration. A preset should point to an npm module that has a jest-preset.json or jest-preset.js file at the root.

For example, this preset foo-bar/jest-preset.js will be configured as follows:

Presets may also be relative to filesystem paths.

prettierPath [string]#

Default: 'prettier'

Sets the path to the prettier node module used to update inline snapshots.

projects [array<string | ProjectConfig>]#

Default: undefined

When the projects configuration is provided with an array of paths or glob patterns, Jest will run tests in all of the specified projects at the same time. This is great for monorepos or when working on multiple projects at the same time.

This example configuration will run Jest in the root directory as well as in every folder in the examples directory. You can have an unlimited amount of projects running in the same Jest instance.

The projects feature can also be used to run multiple configurations or multiple runners. For this purpose, you can pass an array of configuration objects. For example, to run both tests and ESLint (via jest-runner-eslint) in the same invocation of Jest:

Note: When using multi-project runner, it’s recommended to add a displayName for each project. This will show the displayName of a project next to its tests.

reporters [array<moduleName | [moduleName, options]>]#

Default: undefined

Use this configuration option to add custom reporters to Jest. A custom reporter is a class that implements onRunStart, onTestStart, onTestResult, onRunComplete methods that will be called when any of those events occurs.

If custom reporters are specified, the default Jest reporters will be overridden. To keep default reporters, default can be passed as a module name.

This will override default reporters:

This will use custom reporter in addition to default reporters that Jest provides:

Additionally, custom reporters can be configured by passing an options object as a second argument:

Custom reporter modules must define a class that takes a GlobalConfig and reporter options as constructor arguments:

Example reporter:

Custom reporters can also force Jest to exit with non-0 code by returning an Error from getLastError() methods

For the full list of methods and argument types see Reporter interface in packages/jest-reporters/src/types.ts

resetMocks [boolean]#

Default: false

Automatically reset mock state before every test. Equivalent to calling jest.resetAllMocks() before each test. This will lead to any mocks having their fake implementations removed but does not restore their initial implementation.

resetModules [boolean]#

Default: false

By default, each test file gets its own independent module registry. Enabling resetModules goes a step further and resets the module registry before running each individual test. This is useful to isolate modules for every test so that the local module state doesn’t conflict between tests. This can be done programmatically using jest. resetModules().

resolver [string]#

Default: undefined

This option allows the use of a custom resolver. This resolver must be a node module that exports a function expecting a string as the first argument for the path to resolve and an object with the following structure as the second argument:

The function should either return a path to the module that should be resolved or throw an error if the module can’t be found.

Note: the defaultResolver passed as an option is the Jest default resolver which might be useful when you write your custom one. It takes the same arguments as your custom one, e.g. (request, options).

For example, if you want to respect Browserify’s "browser" field, you can use the following configuration:

By combining defaultResolver and packageFilter we can implement a package.json «pre-processor» that allows us to change how the default resolver will resolve modules. For example, imagine we want to use the field "module" if it is present, otherwise fallback to "main":

restoreMocks [boolean]#

Default: false

Automatically restore mock state before every test. Equivalent to calling jest.restoreAllMocks() before each test. This will lead to any mocks having their fake implementations removed and restores their initial implementation.

rootDir [string]#

Default: The root of the directory containing your Jest config file or the package.json or the pwd if no package.json is found

The root directory that Jest should scan for tests and modules within. If you put your Jest config inside your package.json and want the root directory to be the root of your repo, the value for this config param will default to the directory of the package. json.

Oftentimes, you’ll want to set this to 'src' or 'lib', corresponding to where in your repository the code is stored.

Note that using '<rootDir>' as a string token in any other path-based config settings will refer back to this value. So, for example, if you want your setupFiles config entry to point at the env-setup.js file at the root of your project, you could set its value to ["<rootDir>/env-setup.js"].

roots [array<string>]#

Default: ["<rootDir>"]

A list of paths to directories that Jest should use to search for files in.

There are times where you only want Jest to search in a single sub-directory (such as cases where you have a src/ directory in your repo), but prevent it from accessing the rest of the repo.

Note: While rootDir is mostly used as a token to be re-used in other configuration options, roots is used by the internals of Jest to locate test files and source files. This applies also when searching for manual mocks for modules from node_modules (__mocks__ will need to live in one of the roots).

Note: By default, roots has a single entry <rootDir> but there are cases where you may want to have multiple roots within one project, for example roots: ["<rootDir>/src/", "<rootDir>/tests/"].

runner [string]#

Default: "jest-runner"

This option allows you to use a custom runner instead of Jest’s default test runner. Examples of runners include:

Note: The runner property value can omit the jest-runner- prefix of the package name.

To write a test-runner, export a class with which accepts globalConfig in the constructor, and has a runTests method with the signature:

If you need to restrict your test-runner to only run in serial rather than being executed in parallel your class should have the property isSerial to be set as true.

setupFiles [array]#

Default: []

A list of paths to modules that run some code to configure or set up the testing environment. Each setupFile will be run once per test file. Since every test runs in its own environment, these scripts will be executed in the testing environment immediately before executing the test code itself.

It’s also worth noting that setupFiles will execute before setupFilesAfterEnv.

setupFilesAfterEnv [array]#

Default: []

A list of paths to modules that run some code to configure or set up the testing framework before each test file in the suite is executed. Since setupFiles executes before the test framework is installed in the environment, this script file presents you the opportunity of running some code immediately after the test framework has been installed in the environment.

If you want a path to be relative to the root directory of your project, please include <rootDir> inside a path’s string, like "<rootDir>/a-configs-folder".

For example, Jest ships with several plug-ins to jasmine that work by monkey-patching the jasmine API. If you wanted to add even more jasmine plugins to the mix (or if you wanted some custom, project-wide matchers for example), you could do so in these modules.

Note: setupTestFrameworkScriptFile is deprecated in favor of setupFilesAfterEnv.

Example setupFilesAfterEnv array in a jest.config.js:

Example jest.setup.js file

slowTestThreshold [number]#

Default: 5

The number of seconds after which a test is considered as slow and reported as such in the results.

snapshotResolver [string]#

Default: undefined

The path to a module that can resolve test<->snapshot path. This config option lets you customize where Jest stores snapshot files on disk.

Example snapshot resolver module:

snapshotSerializers [array<string>]#

Default: []

A list of paths to snapshot serializer modules Jest should use for snapshot testing.

Jest has default serializers for built-in JavaScript types, HTML elements (Jest 20.0.0+), ImmutableJS (Jest 20.0.0+) and for React elements. See snapshot test tutorial for more information.

Example serializer module:

printer is a function that serializes a value using existing plugins.

To use my-serializer-module as a serializer, configuration would be as follows:

Finally tests would look as follows:

Rendered snapshot:

To make a dependency explicit instead of implicit, you can call expect.addSnapshotSerializer to add a module for an individual test file instead of adding its path to snapshotSerializers in Jest configuration.

More about serializers API can be found here.

testEnvironment [string]#

Default: "jsdom"

The test environment that will be used for testing. The default environment in Jest is a browser-like environment through jsdom. If you are building a node service, you can use the node option to use a node-like environment instead.

By adding a @jest-environment docblock at the top of the file, you can specify another environment to be used for all tests in that file:

You can create your own module that will be used for setting up the test environment. The module must export a class with setup, teardown and runScript methods. You can also pass variables from this module to your test suites by assigning them to this.global object – this will make them available in your test suites as global variables.

The class may optionally expose an asynchronous handleTestEvent method to bind to events fired by jest-circus. Normally, jest-circus test runner would pause until a promise returned from handleTestEvent gets fulfilled, except for the next events: start_describe_definition, finish_describe_definition, add_hook, add_test or error (for the up-to-date list you can look at SyncEvent type in the types definitions). That is caused by backward compatibility reasons and process.on('unhandledRejection', callback) signature, but that usually should not be a problem for most of the use cases.

Any docblock pragmas in test files will be passed to the environment constructor and can be used for per-test configuration. If the pragma does not have a value, it will be present in the object with its value set to an empty string. If the pragma is not present, it will not be present in the object.

To use this class as your custom environment, refer to it by its full path within the project. For example, if your class is stored in my-custom-environment.js in some subfolder of your project, then the annotation might looke like this:

Note: TestEnvironment is sandboxed. Each test suite will trigger setup/teardown in their own TestEnvironment.

Example:

testEnvironmentOptions [Object]#

Default: {}

Test environment options that will be passed to the testEnvironment. The relevant options depend on the environment. For example, you can override options given to jsdom such as {userAgent: "Agent/007"}.

testFailureExitCode [number]#

Default: 1

The exit code Jest returns on test failure.

Note: This does not change the exit code in the case of Jest errors (e.g. invalid configuration).

testMatch [array<string>]#

(default: [ "**/__tests__/**/*.[jt]s?(x)", "**/?(*.)+(spec|test).[jt]s?(x)" ])

The glob patterns Jest uses to detect test files. By default it looks for .js, .jsx, .ts and .tsx files inside of __tests__ folders, as well as any files with a suffix of .test or .spec (e.g. Component.test.js or Component.spec.js). It will also find files called test.js or spec.js.

See the micromatch package for details of the patterns you can specify.

See also testRegex [string | array<string>], but note that you cannot specify both options.

testPathIgnorePatterns [array<string>]#

Default: ["/node_modules/"]

An array of regexp pattern strings that are matched against all test paths before executing the test. If the test path matches any of the patterns, it will be skipped.

testRegex [string | array<string>]#

Default: (/__tests__/.*|(\\.|/)(test|spec))\\.[jt]sx?$

The pattern or patterns Jest uses to detect test files. By default it looks for .js, .jsx, .ts and .tsx files inside of __tests__ folders, as well as any files with a suffix of .test or .spec (e.g. Component.test.js or Component.spec.js). It will also find files called test.js or spec.js. See also testMatch [array<string>], but note that you cannot specify both options.

The following is a visualization of the default regex:

Note: testRegex will try to detect test files using the absolute file path, therefore, having a folder with a name that matches it will run all the files as tests

testResultsProcessor [string]#

Default: undefined

This option allows the use of a custom results processor. This processor must be a node module that exports a function expecting an object with the following structure as the first argument and return it:

testRunner [string]#

Default: jasmine2

This option allows the use of a custom test runner. The default is jasmine2. A custom test runner can be provided by specifying a path to a test runner implementation.

The test runner module must export a function with the following signature:

An example of such function can be found in our default jasmine2 test runner package.

testSequencer [string]#

Default: @jest/test-sequencer

This option allows you to use a custom sequencer instead of Jest’s default. sort may optionally return a Promise.

Example:

Sort test path alphabetically.

Use it in your Jest config file like this:

testTimeout [number]#

Default: 5000

Default timeout of a test in milliseconds.

testURL [string]#

Default: http://localhost

This option sets the URL for the jsdom environment. It is reflected in properties such as location.href.

timers [string]#

Default: real

Setting this value to legacy or fake allows the use of fake timers for functions such as setTimeout. Fake timers are useful when a piece of code sets a long timeout that we don’t want to wait for in a test.

If the value is modern, @sinonjs/fake-timers will be used as implementation instead of Jest’s own legacy implementation. This will be the default fake implementation in Jest 27.

transform [object\<string, pathToTransformer | [pathToTransformer, object]>]#

Default: {"\\.[jt]sx?$": "babel-jest"}

A map from regular expressions to paths to transformers. A transformer is a module that provides a synchronous function for transforming source files. \\\/]+$»]

An array of regexp pattern strings that are matched against all source file paths before transformation. If the test path matches any of the patterns, it will not be transformed.

Example: ["<rootDir>/bower_components/", "<rootDir>/node_modules/"].

Sometimes it happens (especially in React Native or TypeScript projects) that 3rd party modules are published as untranspiled. Since all files inside node_modules are not transformed by default, Jest will not understand the code in these modules, resulting in syntax errors. To overcome this, you may use transformIgnorePatterns to allow transpiling such modules. You’ll find a good example of this use case in React Native Guide.

unmockedModulePathPatterns [array<string>]#

Default: []

An array of regexp pattern strings that are matched against all modules before the module loader will automatically return a mock for them. If a module’s path matches any of the patterns in this list, it will not be automatically mocked by the module loader.

This is useful for some commonly used ‘utility’ modules that are almost always used as implementation details almost all the time (like underscore/lo-dash, etc). It’s generally a best practice to keep this list as small as possible and always use explicit jest.mock()/jest.unmock() calls in individual tests. Explicit per-test setup is far easier for other readers of the test to reason about the environment the test will run in.

It is possible to override this setting in individual tests by explicitly calling jest.mock() at the top of the test file.

verbose [boolean]#

Default: false

Indicates whether each individual test should be reported during the run. All errors will also still be shown on the bottom after execution. Note that if there is only one test file being run it will default to true.

watchPathIgnorePatterns [array<string>]#

Default: []

An array of RegExp patterns that are matched against all source file paths before re-running tests in watch mode. If the file path matches any of the patterns, when it is updated, it will not trigger a re-run of tests.

These patterns match against the full path. Use the <rootDir> string token to include the path to your project’s root directory to prevent it from accidentally ignoring all of your files in different environments that may have different root directories. Example: ["<rootDir>/node_modules/"].

Even if nothing is specified here, the watcher will ignore changes to any hidden files and directories, i.e. files and folders that begin with a dot (.).

watchPlugins [array<string | [string, Object]>]#

Default: []

This option allows you to use custom watch plugins. Read more about watch plugins here.

Examples of watch plugins include:

Note: The values in the watchPlugins property value can omit the jest-watch- prefix of the package name.

watchman [boolean]#

Default: true

Whether to use watchman for file crawling.

// [string]#

No default

This option allows comments in package.json. Include the comment text as the value of this key anywhere in package.json.

Example:

Конфигурация | Vue CLI

Глобальная конфигурация CLI

Некоторые глобальные настройки для @vue/cli, такие как предпочитаемый менеджер пакетов и ваши локальные пресеты настроек, сохранены в JSON-файле . vuerc в вашем домашнем каталоге. Вы можете использовать любой редактор для изменения этих настроек.

Также можно воспользоваться командой vue config для изучения или изменения глобальной конфигурации CLI.

Целевые браузеры

Подробнее в разделе совместимость с браузерами.

vue.config.js

vue.config.js — опциональный файл конфигурации, которую автоматически загружает @vue/cli-service если находит его в корневом каталоге вашего проекта (рядом с файлом package.json). Вы также можете использовать поле vue в package.json, но, обратите внимание, в таком случае вы будете ограничены только JSON-совместимыми значениями.

Файл должен экспортировать объект с настройками:

baseUrl

Устаревшая опция, начиная с версии Vue CLI 3.3, используйте вместо неё publicPath.

publicPath

Тип: string
По умолчанию: '/'
Базовый URL-адрес сборки вашего приложения, по которому оно будет опубликовано (именуемая как baseUrl до версии Vue CLI 3.3). Это аналог опции webpack output.publicPath, но Vue CLI также использует это значение в других целях, поэтому вы должны всегда использовать publicPath вместо изменения опции output.publicPath.
По умолчанию Vue CLI считает, что публикация будет выполнена в корень домена, например https://www.my-app.com/. Если приложение публикуется в подкаталог, то необходимо указать этот путь с помощью этой опции. Например, если приложение будет публиковаться по адресу https://www.foobar.com/my-app/, установите publicPath в значение '/my-app/'.
Значение также может быть пустой строкой ('') или относительным путём (./), чтобы все ресурсы подключались через относительные пути. Это позволит публиковать сборку в любой публичный каталог, или использовать в окружении файловой системы, например в гибридном приложении Cordova.
Ограничения относительного publicPath
Относительный publicPath имеет некоторые ограничения и его следует избегать если:
- Вы используете маршрутизацию HTML5 history.pushState;
- Вы используете опцию pages для создания многостраничного приложения (MPA).
Опция может быть полезна и на этапе разработки. Если вы хотите запускать сервер разработки из корня сайта, то можно устанавливать значение по условию:

outputDir

Тип: string
По умолчанию: 'dist'
Каталог, в котором при запуске vue-cli-service build будут создаваться файлы сборки для production. Обратите внимание, что этот каталог удаляется каждый раз перед началом сборки (это поведение можно отключить опцией --no-clean в команде сборки).
Совет
Всегда используйте outputDir вместо изменения опции webpack output.path.

assetsDir

Тип: string
По умолчанию: ''
Каталог (относительно outputDir) для хранения сгенерированных статических ресурсов (js, css, img, fonts).
Совет
assetsDir игнорируется при перезаписи опций имени файла (filename) или имени фрагментов (chunkFilename) сгенерированных ресурсов.

indexPath

Тип: string
По умолчанию: 'index.html'
Путь к сгенерированному index.html (относительно outputDir). Также можно указать абсолютный путь.

filenameHashing

Тип: boolean
По умолчанию: true
По умолчанию генерируемые статические ресурсы содержат хэши в именах файлов для лучшего управления кэшированием. Однако для этого требуется чтобы индексный HTML автоматически генерировался Vue CLI. Если вы не можете использовать индексный HTML, генерируемый CLI, можно отключить хэширование в именах файлов, установив параметр в значение false.

pages

Тип: Object
По умолчанию: undefined
Сборка приложения в многостраничном режиме (MPA). У каждой «страницы» должна быть соответствующая точка входа (entry) в виде JavaScript-файла. Значением может быть объект, где ключ — имя точки входа, а значение:
- объектом, который определяет свои entry, template, filename, title и chunks (все опциональные, за исключением entry). Любые другие свойства, указанные рядом с ними будут переданы непосредственно в html-webpack-plugin, для возможности более тонкой настройки этого плагина;
- или строкой, определяющей свою entry.
Совет
При сборке в многостраничном режиме, конфигурация webpack будет содержать разные плагины (будут несколько экземпляров html-webpack-plugin и preload-webpack-plugin). Чтобы убедиться в корректности, проверяйте конфигурацию командой vue inspect, если вы изменяете настройки для этих плагинов.

lintOnSave

Тип: boolean | 'warning' | 'default' | 'error'
По умолчанию: ‘default’
Выполнять ли линтинг кода при сохранении во время разработки с помощью eslint-loader. Эта опция действует только когда установлен плагин @vue/cli-plugin-eslint.
Когда значение true или 'warning', eslint-loader показывает ошибки линтинга как предупреждения. По умолчанию предупреждения выводятся в терминал и не останавливают сборку ошибкой, поэтому это хорошее значение по умолчанию для разработки.
Для отображения ошибок линтинга в браузере можно указать lintOnSave: 'default'. Это заставит eslint-loader генерировать ошибки и любые ошибки линтинга приведут к неудаче компиляции сборки.
Установка значения в 'error' заставит eslint-loader считать все предупреждения ошибками, а значит и они будут отображены в браузере.
Кроме того, можно настроить отображение в браузере предупреждений и ошибок:
Когда значение lintOnSave приводится к true, eslint-loader будет применяться как в разработке, так и в production. Если вы хотите отключить eslint-loader при сборке в production, можете воспользоваться следующей конфигурацией:

runtimeCompiler

Тип: boolean
По умолчанию: false
Использование сборки Vue которая содержит компилятор шаблонов. Установка значения в true позволит вам использовать опцию template в компонентах Vue, но дополнительно добавит 10 КБайт кода в ваше приложение.
См. также: Runtime + Компилятор vs. Runtime-only.

transpileDependencies

Тип: Array<string | RegExp>
По умолчанию: []
По умолчанию babel-loader игнорирует все файлы из node_modules. Если вы хотите явно транспилировать зависимость с помощью Babel, то вы можете перечислить её в этой опции.

Конфигурация Jest

Эта опция не поддерживается плагином cli-unit-jest, потому что в Jest мы не должны транспилировать код из node_modules, если в нём не используются нестандартные возможности — Node >8.11 уже поддерживает последние нововведения ECMAScript.

Однако, Jest иногда требуется преобразовывать содержимое из node_modules, например если в этом коде используется синтаксис ES6 import/export. В таком случае используйте опцию transformIgnorePatterns в файле jest.config.js.

См. README плагина для получения дополнительной информации.

productionSourceMap

Тип: boolean
По умолчанию: true
Установка в false может ускорить сборку для production, если не требуются source maps.

crossorigin

Тип: string
По умолчанию: undefined
Настройка атрибутов crossorigin для тегов <link rel="stylesheet"> и <script> в сгенерированном HTML.
Обратите внимание, это повлияет только на теги, внедряемые html-webpack-plugin — теги, добавленные непосредственно в шаблон (public/index.html) не затрагиваются.
См. также: настройка атрибутов CORS

integrity

Тип: boolean
По умолчанию: false
Установите в значение true, чтобы использовать Subresource Integrity (SRI) для тегов <link rel="stylesheet"> и <script> в сгенерированном HTML. Если файлы сборки будут размещены на CDN, то рекомендуется включать опцию для дополнительной безопасности.
Обратите внимание, это повлияет только на теги внедряемые html-webpack-plugin — теги добавленные непосредственно в шаблон (public/index.html) не затрагиваются.
Кроме того, когда включён SRI, подсказки preload ресурсов отключены из-за ошибки в Chrome, которая заставляет ресурсы загружаться дважды.

configureWebpack

Тип: Object | Function
Если значение объект — он будет объединён в финальную конфигурацию с помощью webpack-merge.
Если значение функция — она получит итоговую конфигурацию в качестве аргумента. Функция может либо изменить конфигурацию, либо ничего не возвращать, ИЛИ вернуть клонированную или объединённую версию конфигурации.
См. также: Работа с Webpack — Простая конфигурация

chainWebpack

css.modules

Устаревшая опция, начиная с версии v4, используйте вместо неё css.requireModuleExtension.

В версии v3 это противоположность опции css.requireModuleExtension.

css.requireModuleExtension

Тип: boolean
По умолчанию: true
По умолчанию, только файлы заканчивающиеся на *.module.[ext] обрабатываются как CSS-модули. Установка в значение false позволит вам убрать .module из имён файлов и обрабатывать все *.(css|scss|sass|less|styl(us)?) файлы как CSS-модули.
СОВЕТ
Если в css.loaderOptions.css есть настроенные конфигурации CSS-модулей, то поле css.requireModuleExtension должно быть явно указано в true или false, иначе нельзя быть уверенным необходимо ли применять эти параметры ко всем CSS-файлам или нет.
См. также: Работа с CSS — CSS-модули

Тип: boolean | Object
По умолчанию: true в режиме production, false в режиме development
Извлечение CSS из ваших компонентов в отдельные CSS-файлы (вместо инлайна в JavaScript и динамического внедрения).
Это всегда отключается при сборке веб-компонентов (в этом случае инлайн стили внедряются в shadowRoot).
При сборке библиотеки вы можете также установить значение в false чтобы вашим пользователям не приходилось импортировать CSS самостоятельно.
Извлечение CSS отключено по умолчанию в режиме development, поскольку оно несовместимо с горячей перезагрузкой CSS. Тем не менее, вы всё равно можете принудительно использовать извлечение стилей всегда, установив значение в true.
Вместо true также можно передать объект с настройками для mini-css-extract-plugin если необходимо детальнее настроить работу этого плагина.

css.sourceMap

Тип: boolean
По умолчанию: false
Использование source maps для CSS. Установка этого значения в true может повлиять на производительность сборки.

css.loaderOptions

Тип: Object
По умолчанию: {}
Передача настроек в загрузчики относящиеся к CSS. Например:
Поддерживаемые загрузчики:
Также можно настроить синтаксис scss отдельно от sass через опцию scss.
См. также: Передача настроек в загрузчики пре-процессоров
Совет
Этот способ предпочтительнее, чем менять вручную конкретные загрузчики через chainWebpack, так как эти параметры могут применяться в нескольких местах, где используется соответствующий загрузчик.

devServer

Тип: Object
Поддерживаются все настройки для webpack-dev-server, но следует обратить внимание:
- Некоторые значения, такие как host, port и https, могут перезаписываться флагами командной строки.
- Некоторые значения, такие как publicPath и historyApiFallback, нельзя изменять, поскольку они должны быть синхронизированы с publicPath для правильной работы сервера разработки.

devServer.proxy

Тип: string | Object
Если ваше фронтенд-приложение и бэкенд сервер API не работают на одном хосте, то вам понадобится на этапе разработки проксировать запросы к API. Это можно настроить с помощью опции devServer.proxy в файле vue.config.js.
devServer.proxy может быть строкой, указывающей на сервер API для разработки:
Это скажет серверу разработки проксировать любые неизвестные запросы (запросы, которые не соответствуют статическому файлу) на адрес http://localhost:4000.
ПРЕДУПРЕЖДЕНИЕ
При указании devServer.proxy строкой будут проксироваться только XHR-запросы. Если необходимо протестировать API URL, не открывайте его в браузере, а вместо этого используйте инструмент для работы с API (например, Postman).
Если вам нужно больше контроля поведения прокси-сервера, вы также можете использовать объект с парами опций path: options. См. полный список опций http-proxy-middleware:

parallel

Тип: boolean | number
По умолчанию: require('os').cpus().length > 1
Использовать ли thread-loader для транспиляции Babel или TypeScript. Включается для production-сборок, когда система имеет более 1 процессорных ядер. Указание числа определит количество задействованных воркеров (workers).

Внимание

Не используйте parallel в комбинации с не-сериализуемыми опциями загрузчика, такими как регулярные выражения, даты и функции. Такие опции не будут корректно переданы соответствующим загрузчикам, что может привести к неожиданным ошибкам.

pwa

pluginOptions

Тип: Object
Этот объект не проходит никакой валидации своей структуры, поэтому можно его использовать для передачи произвольных параметров сторонним плагинам. Например:

Babel

Babel можно настроить через файл конфигурации babel.config.js.

Совет

Vue CLI использует babel.config.js — новый формат конфигурации Babel 7. В отличие от .babelrc или поля babel в package.json, этот файл конфигурации не использует разрешение на основе расположения файлов в проекте и последовательно применяется к каждому файлу, включая зависимости внутри node_modules. Рекомендуется всегда использовать babel.config.js в проектах Vue CLI вместо других форматов.

Все приложения Vue CLI используют @vue/babel-preset-app, который включает в себя babel-preset-env, поддержку JSX и оптимизированную конфигурацию для получения итоговой сборки минимального размера. Подробнее в его документации и опциях пресета.

Подробнее в разделе Полифилы этого руководства.

ESLint

ESLint можно настроить через .eslintrc или поле eslintConfig в файле package.json.

Подробнее на странице плагина @vue/cli-plugin-eslint.

TypeScript

TypeScript можно настроить через tsconfig.json.

Подробнее на странице плагина @vue/cli-plugin-typescript.

Модульное тестирование

Jest

Подробнее на странице плагина @vue/cli-plugin-unit-jest.

Mocha (через

mocha-webpack)

Подробнее на странице плагина @vue/cli-plugin-unit-mocha.

E2E тестирование

Cypress

Подробнее на странице плагина @vue/cli-plugin-e2e-cypress.

Nightwatch

Подробнее на странице плагина @vue/cli-plugin-e2e-nightwatch.

WebdriverIO

Подробнее на странице плагина @vue/cli-plugin-e2e-webdriverio.

Конфигурация

— npm

примечания к выпуску

Введение

Node-config организует иерархические конфигурации для развертываний ваших приложений.

Позволяет определить набор параметров по умолчанию,
и расширить их для различных сред развертывания (разработка, qa,
постановка, постановка и др.).

Конфигурации хранятся в файлах конфигурации в вашем приложении и могут быть переопределены и расширены с помощью переменных среды,
параметры командной строки или внешние источники.

Это дает вашему приложению согласованный интерфейс конфигурации, совместно используемый
растущий список модулей npm, также использующих node-config.

Руководство проекта

Простой — Начните быстро
Мощный — для многоузлового развертывания на предприятии
Гибкий — Поддержка нескольких форматов файлов конфигурации
Легкий — Малый размер файла и памяти
Predictable — Хорошо протестированная основа для разработчиков модулей и приложений

Быстрый старт

Следующие примеры представлены в формате JSON, но конфигурации могут быть в других форматах файлов.

Установите в каталог приложения и отредактируйте файл конфигурации по умолчанию.

 $ npm установить конфигурацию
Конфигурация $ mkdir
$ vi config / default.json

 {
  // Конфиги клиентского модуля
  "Покупатель": {
    "dbConfig": {
      "хост": "локальный хост",
      «порт»: 5984,
      «dbName»: «клиенты»
    },
    "кредит": {
      "initialLimit": 100,
      // Устанавливаем низкое значение для разработки
      "initialDays": 1
    }
  }
}

Изменить переопределения конфигурации для производственного развертывания:

 $ vi config / production.json

 {
  "Покупатель": {
    "dbConfig": {
      "хост": "prod-db-server"
    },
    "кредит": {
      «initialDays»: 30
    }
  }
}

Используйте конфиги в своем коде:

 const config = require ('config');
// ...
const dbConfig = config.get ('Customer.dbConfig');
db.connect (dbConfig, ...);

if (config.has ('optionalFeature.detail')) {
  const detail = config.get ('optionalFeature.detail');
  // ...
}

config.get () выдаст исключение для неопределенных ключей, чтобы помочь отловить опечатки и пропущенные значения.Используйте config.has () , чтобы проверить, определено ли значение конфигурации.

Запустите сервер приложений:

 $ экспорт NODE_ENV = производство
$ node my-app.js

Работая в этой конфигурации, порт и элементы dbName из dbConfig
будет происходить из файла default.json , а элемент host будет
взяты из файла переопределения production.json .

Статьи

Дополнительная информация

Если вы по-прежнему не видите то, что ищете, можно проверить еще несколько ресурсов:

Авторы

Лицензия

Может свободно распространяться по лицензии MIT.

Node.

js Best Practices — более разумные способы управления файлами конфигурации и переменными | by Raj Chaudhary

Мне кажется обременительной практика создания отдельных файлов конфигурации Node.js для управления переменными конфигурации для различных сред (разработка, тестирование, постановка и производство).

Итак, я пришел к решению, которое управляет переменными конфигурации для всех сред с помощью одного файла конфигурации Node.js.

Сначала создадим config.json в папке root / config, как показано ниже. Идея состоит в том, что разработка является средой по умолчанию и содержит все переменные конфигурации. Вы только повторяете переменные конфигурации в других средах, если хотите переопределить значения переменных конфигурации по умолчанию, найденные в среде разработки по умолчанию.

Итак, как вы видите, тестовая, промежуточная и производственная среды переопределяют переменные config_id и базы данных. А промежуточные и производственные среды также переопределяют переменную конфигурации node_port.

Затем давайте напишем код для реализации реальной логики. Создайте config.js в корневой папке / config, как показано ниже. Этот код:

Считывает JSON из файла root / config.json.
Устанавливает конфигурацию по умолчанию для узла разработки, находящегося в config.json.
Устанавливает конфигурацию среды для соответствующего узла среды, найденного в config.json, на основе значения переменной среды NODE_ENV (которая сама по умолчанию используется для разработки, если она равна нулю).
Устанавливает окончательную конфигурацию на объединение конфигурации по умолчанию и конфигурации среды, вызывая метод слияния lodash.
Устанавливает глобальную переменную gConfig со значением окончательной конфигурации.
Регистрирует значение gConfig.

Наконец, давайте создадим root / server.js, чтобы протестировать все это в браузере. Код ниже не требует пояснений. Проверьте это, установив разные значения для переменной среды NODE_ENV.

А вот несколько скриншотов из тестирования с установкой переменной среды NODE_ENV в server.js для разработки и постановки. Вы можете видеть, что для промежуточной среды значения app_name, app_desc и json_indentation не меняются и берутся из среды разработки, где значения config_id, node_port и database переопределяются.

Выходные данные журнала для среды разработки Выходные данные браузера для среды разработки Выходные данные журнала для промежуточной среды Выходные данные браузера для промежуточной среды

Вы можете клонировать / загрузить приведенный выше код из моего репозитория GitHub здесь.

В качестве бонуса ничто не мешает вам включать такие секреты, как ключи API или пароли, в config.json. Просто зашифруйте его в неактивном состоянии, прежде чем отправлять в исходный репозиторий, с помощью решения для шифрования корпоративного уровня, такого как Cloud Key Management Service (KMS) Google Cloud Platform.И расшифровывайте его при каждом развертывании, используя свой любимый инструмент CI / CD.

Ознакомьтесь с моим сообщением в блоге Использование службы управления ключами облака (KMS) Google Cloud Platform для шифрования / дешифрования секретов для получения дополнительной информации.

Удачного кодирования!

GitHub — lorenwest / node-config: Конфигурация приложения Node.js

примечания к выпуску

Введение

Node-config организует иерархические конфигурации для развертываний ваших приложений.

Руководство проекта

Простой — Начните быстро
Мощный — для многоузлового развертывания на предприятии
Гибкий — Поддержка нескольких форматов файлов конфигурации
Легкий — Малый размер файла и памяти
Predictable — Хорошо протестированная основа для разработчиков модулей и приложений

Быстрый старт

Следующие примеры представлены в формате JSON, но конфигурации могут быть в других форматах файлов.

Установите в каталог приложения и отредактируйте файл конфигурации по умолчанию.

 $ npm установить конфигурацию
Конфигурация $ mkdir
$ vi config / default.json

 {
  // Конфиги клиентского модуля
  "Покупатель": {
    "dbConfig": {
      "хост": "локальный хост",
      «порт»: 5984,
      «dbName»: «клиенты»
    },
    "кредит": {
      "initialLimit": 100,
      // Устанавливаем низкое значение для разработки
      "initialDays": 1
    }
  }
}

Изменить переопределения конфигурации для производственного развертывания:

 $ vi config / production.json

 {
  "Покупатель": {
    "dbConfig": {
      "хост": "prod-db-server"
    },
    "кредит": {
      «initialDays»: 30
    }
  }
}

Используйте конфиги в своем коде:

 const config = require ('config');
// ...
const dbConfig = config.get ('Customer.dbConfig');
db.connect (dbConfig, ...);

if (config.has ('optionalFeature.detail')) {
  const detail = config.get ('optionalFeature.detail');
  // ...
}

Запустите сервер приложений:

 $ экспорт NODE_ENV = производство
$ node my-app. js

Статьи

Дополнительная информация

Если вы по-прежнему не видите то, что ищете, можно проверить еще несколько ресурсов:

Авторы

Лицензия

Может свободно распространяться по лицензии MIT.

Как сохранить локальные данные конфигурации

Хранить данные конфигурации вашего приложения Node.js довольно просто — каждый объект в JavaScript можно легко отобразить как JSON, который, в свою очередь, представляет собой просто строковые данные, которые можно отправлять или сохранять любым удобным для вас способом. Самый простой способ сделать это — использовать встроенные методы JSON.parse () и JSON.stringify () .

Давайте посмотрим на очень простой (и надуманный) пример.Во-первых, чтобы сохранить очень простые данные:

  var fs = require ('fs');

var myOptions = {
  имя: 'Птичий',
  десерт: торт
  аромат: "шоколадный",
  напиток: 'кофе'
};

var data = JSON.stringify (myOptions);

fs.writeFile ('./ config.json', data, function (err) {
  if (err) {
    console.log («Произошла ошибка при сохранении данных конфигурации.»);
    console.log (сообщение об ошибке);
    возвращаться;
  }
  console.log ('Конфигурация успешно сохранена.')
});

Это действительно так просто — всего JSON.stringify () , а затем сохраните его, как хотите.

Теперь загрузим некоторые данные конфигурации:

  var fs = require ('fs');

var data = fs.readFileSync ('./ config.json'),
    myObj;

пытаться {
  myObj = JSON.parse (данные);
  console.dir (myObj);
}
catch (err) {
  console. log ('Произошла ошибка при синтаксическом анализе вашего JSON.')
  console.log (ошибка);
}

СОВЕТ

NODE PRO: даже если вам не нравится использовать try / catch , это место для его использования. JSON.parse — очень строгий синтаксический анализатор JSON, и ошибки встречаются часто, но самое главное — JSON.parse использует оператор throw вместо обратного вызова, поэтому try / catch — единственный способ защититься от ошибки.

Использование встроенных методов JSON может увести вас далеко, но, как и в случае со многими другими проблемами, которые вы, возможно, захотите решить с помощью Node.js, в Userland уже есть решение, которое может значительно продвинуть вас вперед. В данном случае решение — nconf . Написанный Чарли Роббинсом, это менеджер конфигурации для Node.js, поддерживающий хранение в памяти, локальное файловое хранилище, а также поддержку бэкэнда redis , представленных в отдельном модуле.

Давайте теперь посмотрим, как мы выполняем локальный доступ к конфигурации с помощью nconf . Во-первых, вам нужно установить его в рабочий каталог вашего проекта:

  npm установить nconf

После этого синтаксис становится проще простого. Взгляните на пример:

  var nconf = require ('nconf');

nconf.используйте ('файл', {файл: './config.json'});
nconf.load ();
nconf.set ('имя', 'Авиан');
nconf.set ('десерт: имя', 'Мороженое');
nconf.set ('десерт: аромат', 'шоколад');

console.log (nconf.get ('десерт'));

nconf.save (функция (ошибка) {
  if (err) {
    console.error (сообщение об ошибке);
    возвращаться;
  }
  console.log ('Конфигурация успешно сохранена.');
});

Единственное, что здесь сложно заметить, это разделитель — ‘:’. При доступе к вложенным свойствам с помощью nconf двоеточие используется для разделения пространств имен ключевых имен. Если конкретный подключ не указан, устанавливается или возвращается весь объект.

При использовании nconf для сохранения данных конфигурации в файл, nconf.save () и nconf.load () — единственные случаи, когда происходит какое-либо фактическое взаимодействие с файлом. Весь остальной доступ осуществляется к копии ваших данных в памяти, которая не сохранится без вызова nconf.save () . Точно так же, если вы пытаетесь вернуть данные конфигурации из последнего запуска вашего приложения, они не будут существовать в памяти без вызова nconf.load () , как показано выше.

переменных среды | Gatsby

Вы можете предоставить своему сайту переменные среды, чтобы настроить его поведение в различных средах.

Переменные среды можно разделить на разные типы.

Существуют переменные среды, которые определены в специальных местах, предназначенных для использования в различных средах развертывания. Вы можете назвать их «Project Env Vars».

И есть настоящие переменные среды уровня ОС, которые могут использоваться в вызовах командной строки.Вы можете называть их «OS Env Vars».

В обоих случаях вы хотите иметь доступ к значению этих переменных для среды, в которой вы находитесь.

По умолчанию Gatsby поддерживает 2 среды:

Разработка. Если вы запустите gatsby develop , вы попадете в среду «разработки».
Производство. Если вы запустите gatsby build или gatsby serve , то вы будете в «производственной» среде.

Если вы хотите определить другие среды, вам нужно проделать еще немного работы. См. «Дополнительные среды» ниже. Вы также можете взглянуть на переменные среды CodeSandbox, читая примеры.

Доступ к переменным среды в JavaScript

Все переменные Env проекта и ОС доступны только непосредственно во время сборки, или
когда запущен Node. js. Они не доступны сразу во время выполнения клиентского кода; Oни
должны быть активно захвачены и встроены в клиентский JavaScript.Это достигается во время сборки с помощью DefinePlugin webpack.

После того, как переменные среды были встроены в код на стороне клиента, они становятся доступными из
глобальная переменная process.env .
Переменные Env ОС доступны в Node.js из той же глобальной переменной process.env .

Обратите внимание, что, поскольку эти переменные встроены во время сборки, вам необходимо перезагрузить сервер разработки.
или перестройте свой сайт после их изменения.

Определение переменных среды

Клиентский JavaScript

Для переменных Project Env, к которым вы хотите получить доступ в клиентском браузере JavaScript, вы можете определить
файл конфигурации среды .env.development и / или .env.production в корневой папке.
В зависимости от вашей активной среды будет найдена правильная среда, а ее значения встроены как переменные среды в JavaScript браузера.

В дополнение к этим переменным среды проекта, определенным в файлах .env. * , вы также можете определить
OS Env Vars. OS Env Vars с префиксом GATSBY_ станут доступны в
браузер JavaScript.

Серверный Node.js

Гэтсби запускает несколько узлов.js во время сборки, особенно gatsby-config.js и gatsby-node.js .
OS Env Vars уже будут доступны, когда Node запущен, поэтому вы можете добавить переменные среды
типичные способы, например добавляя переменные среды через ваш инструмент хостинга / сборки, вашу ОС или когда
вызов Гэтсби из командной строки.

В терминалах Linux это можно сделать с помощью:

В Windows это немного сложнее. Ознакомьтесь с этой статьей о переполнении стека, чтобы узнать о некоторых параметрах

Переменные среды проекта, которые вы определили в .env. * Файлы будут доступны сразу после НЕ
в ваших скриптах Node. js. Чтобы использовать эти переменные, используйте пакет npm dotenv для
проверьте активный файл .env. * и приложите эти значения.
dotenv уже является зависимостью от Gatsby, поэтому вы можете потребовать его в своем gatsby-config.js или gatsby-node.js следующим образом:

Теперь переменные доступны в процессе .env как обычно .

Пример использования переменной среды

Обратите внимание, что вы не должны фиксировать .env. * в систему управления версиями и лучше использовать параметры, предоставленные поставщиком непрерывного развертывания (CD). Примером является Netlify с его переменными среды сборки.

Примечание: поскольку Gatsby использует DefinePlugin webpack, чтобы сделать переменные среды доступными во время выполнения, их нельзя деструктурировать из process.env ; вместо этого на них должны быть даны полные ссылки.

GATSBY_API_URL будет доступен вашему сайту (на стороне клиента и на стороне сервера) как процесс .env.GATSBY_API_URL .:

В Node у вашего сайта есть доступ к вашему API_KEY (на стороне сервера) с использованием идентификатора process.env.API_KEY . Для доступа к нему на стороне клиента вы можете использовать файл .env. * , содержащий API_KEY . Однако вам настоятельно рекомендуется не проверять эти файлы в системе управления версиями, поскольку раскрытие ключа API является проблемой безопасности. В качестве более безопасной альтернативы вы можете добавить к переменной префикс GATSBY_ (как показано выше).С этим префиксом Гэтсби автоматически встраивает переменную как process.env.GATSBY \ _ \ * в скомпилированный JS, делая ее доступной в контексте браузера, не раскрывая ее где-либо еще.

Зарезервированные переменные среды:

Вы не можете переопределить определенные переменные среды, так как некоторые из них используются внутри компании.
для оптимизации во время сборки, например:

Gatsby также позволяет указать другую переменную среды при запуске локального сервера разработки (например,грамм. npm run develop ):

ENABLE_GATSBY_REFRESH_ENDPOINT

Это позволяет обновлять исходный контент. См. Обновление содержимого.

Переменные сборки

Gatsby использует дополнительные переменные среды на этапе сборки для точной настройки результата сборки. Вы можете найти их полезными для более сложных конфигураций, таких как использование CI / CD для развертывания сайта Gatsby.

Например, вы можете установить CI = true в качестве переменной среды, чтобы сценарий сборки Gatsby мог адаптировать вывод терминала к среде автоматического развертывания.Некоторые инструменты CI / CD могут уже установить эту переменную среды. Это полезно для ограничения подробности вывода сборки для немых терминалов, таких как анимация выполнения терминала.

Gatsby определяет оптимальный уровень параллелизма для фазы рендеринга gatsby build на основе заявленного количества физических процессоров. Для сборок, которые выполняются в виртуальных средах, вам может потребоваться настроить количество параллелизма рабочих с помощью переменной среды GATSBY_CPU_COUNT .См. Многоядерные сборки.

Дополнительные среды (промежуточные, тестовые и т. Д.)

Как отмечалось выше, NODE_ENV — это зарезервированная переменная среды в Gatsby, поскольку она необходима системе сборки для выполнения ключевых оптимизаций при компиляции React и других модулей. По этой причине необходимо использовать вторичную переменную среды для дополнительной поддержки среды и вручную сделать переменные среды доступными для кода на стороне клиента.

Вы можете определить собственную переменную окружения ОС, чтобы отслеживать активную среду, а затем находить соответствующие переменные среды проекта для загрузки. Сам Gatsby не будет ничего делать с этой ОС Env Var, но вы можете использовать его в gatsby-config.js .

В частности, вы можете использовать dotenv и вашу индивидуальную Env Var ОС, чтобы найти файл .env.myCustomEnvironment , а затем использовать module.exports для хранения этих переменных Project Env в том месте, к которому клиентский JavaScript может получить доступ значения (через запросы GraphQL).

Google Analytics env var example

Если вы хотите добавить промежуточную среду с настраиваемым идентификатором отслеживания Google Analytics и выделенным apiUrl , вы можете добавить .env.staging в корне вашего проекта. Для этого используйте следующую модификацию вашего gatsby-config.js :

Это затем загрузит значения из файла .env. * соответствующей среды и сделает их доступными через запросы GraphQL и плагин аналитики. соответственно.

Локальное тестирование промежуточной среды можно выполнить с помощью:

Конфигурация и управление секретами Node.js | Сергей Чикин

Фото Эмиля Перрона на Unsplash

Щелкните здесь, чтобы опубликовать эту статью в LinkedIn »

За последние пару лет я был в нескольких Node.js, и одна из повторяющихся проблем — это то, как люди управляют конфигурацией и секретами.

Прежде всего, это основные аспекты того, что я пытаюсь достичь с помощью управления конфигурацией / секретами.

Гибкость

Разрешить разработчикам программного обеспечения изменять конфигурацию. В большинстве случаев управление конфигурацией является обязанностью оператора, но это добавляет ненужные накладные расходы и замедляет процесс отладки / исправления. Зачастую параметры конфигурации определяют разработчики, и поэтому они лучше всех знают правильные значения конфигурации.Рассмотрим следующий случай:

Приложение, построенное на Scala (Akka), использует typesafe-config для конфигурации сервера и вместе с ним указывает параметры пула потоков / диспетчера. В какой-то момент приложение начало сталкиваться с серьезными проблемами производительности. Поскольку операторы не обладают достаточным пониманием внутренней архитектуры приложения (они не имеют представления о пулах потоков и еще меньше знают о том, какие участники / фьючерсы работают в каких пулах), процесс исправления будет выглядеть следующим образом:

Разработчик программного обеспечения будет копировать проблема локально
Инженер-программист найдет причину проблемы и после некоторой игры придумает правильные настройки для пулов потоков
Инженер-программист обратится к Ops, чтобы соответствующим образом изменить производственную конфигурацию

На этом этапе процесса 3 не нужно.Более того, с учетом того, что настроен надлежащий конвейер CI / CD и соблюдены надлежащие методы разработки — шаг 3 не будет проходить экспертную оценку и не отслеживается каким-либо образом

Еще более распространенный случай — когда разработчику необходимо поднять уровень отладки для особая услуга. Почему бы не дать разработчику возможность сделать это самому?

Учитывая, что существует экспертная оценка, это потенциально так же нарушает работу, как и любое другое изменение кода.

Безопасность

Секретные значения (пароли БД, ключи доступа к API и т. Д.) Никогда не должны появляться в репо.Период.

Этот аспект немного противоречит «Гибкости», но его довольно легко решить с помощью большинства библиотек конфигурации. Как? У вас есть все несекретные значения в репо, а затем вы вводите секретные значения во время развертывания (я предпочитаю использовать для него переменные ENV)

Подробность

Это очень полезно, чтобы избежать необходимости переопределять всю конфигурацию для каждой среды. Большинство систем конфигурации позволяют это сделать, задав порядок обработки файлов конфигурации. Обычно они начинают с самого общего файла конфигурации, а затем заменяют значения конфигурации более конкретными файлами конфигурации.Если библиотека позволяет это сделать — я бы взял это в любой день.

Пример: настройки пула соединений с БД одинаковы для всех сред (допустим, мин: 2, макс: 10). Но для производственной среды вам нужен более агрессивный пул (мин: 10, макс: 80). Они делают это с помощью config

default.js:

  const  config = {
 database: {
 client: 'mysql', 
 connection: {
 host: 'localhost', 
 user: '', 
 password: '', 
 database: '', 
}, 
 pool: {
 min: 2, 
 max: 10, 
}, 
}, 
}  модуль.export = config;

production.js:

  const  config = {
 database.pool: {
 min: 10, 
 max: 80, 
}, 
}  module.exports = config;

Простота

Дизайнер знает, что он достиг совершенства не тогда, когда нечего добавить, а когда уже нечего убирать.
Антуан де Сент-Экзюпери

Конечно, есть ряд решений, которые решают по крайней мере некоторые из вышеперечисленных проблем.Вопрос в том, действительно ли вы хотите установить дополнительный компонент в свою инфраструктуру только для решения этой проблемы. Дополнительные компоненты имеют повышенную сложность, что приводит к увеличению количества ошибок, увеличению времени отладки и времени реакции

Некоторые из решений, которые я использовал:

HashiCorp Vault — хорошо для управления секретами, но немного излишне, если у вас нет более 9000 микросервисов в десятках ландшафтов
Chef / Puppet / Ansible для управления конфигурацией — опять же, по моему опыту, это отличные инструменты для настройки серверов, но когда дело доходит до настраиваемой конфигурации программного обеспечения, что-то всегда ломается
Системы консенсуса — ZooKeeper / etcd / consul.Некоторые люди используют их, чтобы хранить там всю конфигурацию и заставлять приложения взаимодействовать с ними. В большинстве случаев люди делают это, когда у них уже есть одна из этих систем (например, у людей, использующих Kubernetes, есть etcd из коробки).

Я выполнил большинство из них с переменным успехом. Есть известная русская идиома «забить гвозди с помощью микроскопа», и мне всегда казалось, что это именно то, чем я занимаюсь

Мой путь

В Node.JS есть прекрасная библиотека конфигурации, которая выполняет все трюки и обман за меня. .Структура проекта:

/ - package.json - / src - / config - - /local.js - - /default.js - - /development.js - - /production.js - - /.js - - /custom-environment-variables.js

Содержимое файла выглядит следующим образом:

local.js — содержит полную конфигурацию, должен быть помещен в .gitignore и никогда не появляется в репо
default.js — содержит общие ключи конфигурации верхнего уровня, которые используются во всех средах, с отключенными секретными значениями
— содержит определенные переопределения для конкретной среды. Среда определяется с использованием NODE_ENV переменной среды
custom-environment-variables.js — сопоставляет секретные ключи конфигурации с переменными env, которые будут позже введены во время выполнения

Я обычно использую его с Kubernetes, который позволяет хранить секретные значения и вводите их с помощью переменных окружения удобным способом

Пример репозитория находится здесь

Удачного взлома и не изобретайте велосипед!

Aerospike Источник: конфиг.js

 // ******************************************** ********************************
// Авторское право 2013-2020 Aerospike, Inc.
//
// Под лицензией Apache License, версия 2.0 («Лицензия»)
// вы не можете использовать этот файл, кроме как в соответствии с Лицензией.
// Вы можете получить копию лицензии по адресу
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Если это не требуется действующим законодательством или не согласовано в письменной форме, программное обеспечение
// распространяется по Лицензии распространяется на ОСНОВЕ "КАК ЕСТЬ",
// БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ, явных или подразумеваемых.// См. Лицензию для конкретных языков, управляющих разрешениями и
// ограничения по Лицензии.
// *********************************************** *****************************

'использовать строго'

const policy = require ('./ policy')

const inspect = Symbol.for ('nodejs.util.inspect.custom')

/ **
 * Класс Config содержит настройки для клиента Aerospike.
 * экземпляр, включая список исходных хостов, политики по умолчанию и другие
 * настройки.
 *
 * @throws {TypeError} Если переданы недопустимые значения конфигурации.*
 * @пример
 *
 * const Aerospike = require ('aerospike')
 *
 * let config = {
 * хосты: '192.168.1.10,192.168.1.11',
 * пользователь: process.env.DATABASE_USER,
 * пароль: process.env.DATABASE_PASSWORD,
 * policy: {
 * читайте: новый Aerospike.ReadPolicy ({
 * totalTimeout: 500
 *})
 *},
 *   бревно: {
 * уровень: Aerospike.log.INFO,
 * file: 2 // войти в stderr
 *}
 *}
 *
 * Aerospike.connect (конфиг)
 * .then (client => {
 * // клиент готов принимать команды
 * клиент.Закрыть()
 *})
 * .catch (error => {
 * console.error ('Не удалось подключиться к кластеру:% s', error.message)
 *})
 * /
class Config {
  / **
   * Инициализирует новую конфигурацию клиента из заданных значений конфигурации.
   *
   * @param {Object} [config] значения конфигурации
   * /
  constructor (config) {
    config = config || {}

    / **
     * @name Config # пользователь
     * @summary Имя пользователя для использования при аутентификации в кластере.
     * @description Оставьте пустым для кластеров, работающих без управления доступом.* (Функции безопасности доступны в Aerospike Database Enterprise
     * Версия.)
     * @type {строка}
     * /
    if (typeof config.user === 'строка') {
      this.user = config.user
    }

    / **
     * @name Config # пароль
     * @summary Пароль для использования при аутентификации в кластере.
     * @type {строка}
     * /
    if (typeof config.password === 'строка') {
      this.password = config.password
    }

    / **
     * @name Config # authMode
     * @summary Режим аутентификации, используемый при определении пользователя / пароля.* @description Один из режимов аутентификации, определенных в {@link module: aerospike.auth}.
     * @type {number}
     * @see модуль: aerospike.auth
     * /
    if (typeof config.authMode === 'number') {
      this.authMode = config.authMode
    }

    / **
     * @ имя Config # имя кластера
     * @summary Ожидаемое имя кластера.
     * @description Если не  null , серверные узлы должны возвращать это
     * имя кластера, чтобы присоединиться к взгляду клиента на кластер. Должен
     * устанавливается только при подключении к серверам, поддерживающим "имя-кластера"
     * информационная команда.* @type {строка}
     * @since v2.4
     * /
    this.clusterName = config.clusterName

    / **
     * @name Config # порт
     * @summary Порт по умолчанию для использования для любого адреса хоста, который не
     * явно указать номер порта. По умолчанию 3000.
     * @type {number}
     *
     * @since v2.4
     * /
    if (typeof config.port === 'number') {
      this.port = config.port
    } еще {
      this.port = 3000
    }

    / **
     * @name Config # tls
     * @summary Настроить параметры безопасности транспортного уровня (TLS) для обеспечения безопасности
     * подключения к кластеру базы данных.Подключения TLS не поддерживаются как
     * Aerospike Server v3.9 и зависит от будущей версии сервера.
     * @type {Object}
     * @since v2.4
     *
     * @property {boolean} [enable = true] - включить TLS для подключения сокетов к
     * узлы кластера. По умолчанию TLS включен, только если конфигурация клиента
     * включает раздел  tls .
     * @property {строка} [cafile] - путь к файлу сертификата доверенного ЦС. К
     * TLS по умолчанию будет использовать стандартные системные сертификаты доверенных центров сертификации.* @property {строка} [capath] - Путь к каталогу доверенных сертификатов.
     * См. Дополнительную информацию на странице руководства OpenSSL SSL_CTX_load_verify_locations.
     * информация о формате справочника.
     * @property {строка} [протоколы] - указывает включенные протоколы. Формат
     * то же, что и протокол SSL от Apache, описанный в
     * https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslprotocol. Если не
     * указано, клиент будет использовать "-all + TLSv1.2". Если вы не уверены, что
     * протоколы для выбора этой опции лучше не указывать.* @property {строка} [cipherSuite] - указывает включенные наборы шифров. В
     * формат такой же, как формат списка шифров OpenSSL, описанный в
     * https://www.openssl.org/docs/manmaster/apps/ciphers.html. Если не указано
     * набор шифров по умолчанию OpenSSL, описанный в документации по шифрованию
     * будет использован. Если вы не уверены, какой набор шифров выбрать эту опцию
     * лучше не указывать.
     * @property {строка} [certBlacklist] - путь к файлу черного списка сертификатов.* Файл должен содержать по одной строке для каждого сертификата, занесенного в черный список. Каждый
     * строка начинается с порядкового номера сертификата, выраженного в шестнадцатеричном формате. Каждый
     * запись может дополнительно указывать наименование издателя сертификата. (Серийный
     * номера должны быть уникальными только для каждого эмитента.) Примеры записей:
     *  
 867EC87482B2 / C = US / ST = CA / O = Acme / OU = Engineering / CN = Test Chain CA 

     * E2D4B0E570F9EF8E885C065899886461 
     * @property {string} [keyfile] - Путь к клиентскому ключу для взаимной
     * аутентификация.По умолчанию взаимная аутентификация отключена.
     * @property {string} [keyfilePassword] - пароль для расшифровки
     * клиентский ключ для взаимной аутентификации. По умолчанию предполагается ключ
     * не шифровать.
     * @property {string} [certfile] - путь к цепочке сертификатов клиента.
     * файл для взаимной аутентификации. По умолчанию взаимная аутентификация
     * отключен.
     * @property {boolean} [crlCheck = false] - включить проверку CRL для
     * сертификат листа цепочки сертификатов.Ошибка возникает, если подходящий CRL
     * Не может быть найдено. По умолчанию проверка CRL отключена.
     * @property {boolean} [crlCheckAll = false] - включить проверку CRL для
     * вся цепочка сертификатов. Ошибка возникает, если подходящий CRL не может быть
     * найденный. По умолчанию проверка CRL отключена.
     * @property {boolean} [logSessionInfo = false] - записывать информацию о сеансе для
     * каждое соединение.
     * @property {boolean} [forLoginOnly = false] - использовать TLS-соединения только для входа
     * аутентификация.Все остальные коммуникации с сервером будут выполнены.
     * с подключениями без TLS. По умолчанию: false (Использовать TLS-соединения для всех
     * связь с сервером.)
     * /
    if (typeof config.tls === 'object') {
      this.tls = config.tls
    }

    / **
     * @summary Список хостов, с которыми клиент должен попытаться соединиться.
     * @description Если не указано, клиент пытается прочитать список хостов.
     * из переменной среды  AEROSPIKE_HOSTS , иначе упадет
     * вернуться к использованию значения по умолчанию "localhost".* @type {(Объект [] | строка)}
     *
     * @example  Установка  hosts  с использованием String 
     *
     * const Aerospike = require ('aerospike')
     *
     * var hosts = '192.168.0.1:3000,192.168.0.2:3000'
     * Aerospike.connect ({hosts: hosts}, (err, client) => {
     * if (err) throw err
     * // ...
     * client.close ()
     *})
     *
     * @example  Установка  hosts  с использованием массива кортежей имени хоста / порта 
     *
     * const Aerospike = require ('aerospike')
     *
     * var hosts = [
     * {адрес: '192.168.0.1 ', порт: 3000},
     * {адрес: '192.168.0.2', порт: 3000}
     *]
     * Aerospike.connect ({hosts: hosts}, (err, client) => {
     * if (err) throw err
     * // ...
     * client.close ()
     *})
     * /
    this.hosts = config.hosts || process.env.AEROSPIKE_HOSTS || `localhost: $ {this.port}`

    / **
     * @summary Глобальные клиентские политики.
     *
     * @description Конфигурация определяет политики по умолчанию для
     * заявление. Политики определяют поведение клиента, которое может быть
     * глобальный для всех видов использования одного типа операции или локальный для одного
     * использование операции.*
     * Каждая операция с базой данных принимает политику для этой операции как
     * аргумент. Это считается локальной политикой и является политикой одноразового использования.
     * Эта локальная политика заменяет любую определенную глобальную политику.
     *
     * Если значение политики не определено, то правилом является возврат к
     * глобальная политика для этой операции. Если глобальная политика для этого
     * операция не определена, тогда будет использоваться глобальное значение по умолчанию.
     *
     * Если вы обнаружите, что у вас есть поведение, которое вы хотите при каждом использовании
     * операция для использования, тогда вы можете указать политику по умолчанию как
     * {@link Config # policy}.*
     * Например, операция {@link Client # put} принимает {@link
     * Параметр WritePolicy}. Если вы обнаружите, что настраиваете {@link
     * WritePolicy # key} значение политики для каждого вызова {@link Client.put}, затем
     * может оказаться полезным установить глобальную политику {@link WritePolicy} в
     * {@link Config # policy}, который будет использоваться всеми операциями.
     *
     * @type {Config ~ Policies}
     *
     * @example  Установка политики  key  по умолчанию для всех операций записи 
     *
     * const Aerospike = require ('aerospike')
     *
     * let config = {
     * policy: {
     * напишите: новый Аэроспайк.WritePolicy ({
     * ключ: Aerospike.policy.key.SEND
     *})
     *}
     *}
     * let key = new Aerospike.Key ('test', 'demo', 123).
     *
     * Aerospike.connect (конфиг)
     * .then (client => {
     * return client.put (ключ, {int: 42})
     * .then (() => client.close ())
     * .catch (error => {
     * client.close ()
     * выбросить ошибку
     *})
     *})
     * .catch (console.error)
     * /
    this.policies = {}
    if (typeof config.policy === 'object') {
      this.setDefaultPolicies (config.policies)
    }

    / **
     * @name Config # журнал
     * @summary Конфигурация для ведения журнала, выполняемого клиентом.
     * @type {Object}
     *
     * @property {Number} [log.level] - уровень лога; см. {@link
     * module: aerospike.log} для получения подробной информации.
     * @property {Number} [log.file] - дескриптор файла, возвращаемый
     *  fs.open ()  или один из  process.stdout.fd  или
     * <код> process.stderr.fd .
     *
     * @example  Включение ведения журнала отладки в отдельный файл журнала 
     *
     * const Aerospike = require ('aerospike')
     * const fs = require ('fs')
     *
     * var debuglog = fs.openSync ('./ debug.log')
     * var config = {
     *   бревно: {
     * уровень: Aerospike.log.DEBUG,
     * файл: debuglog
     *}
     *}
     * Aerospike.connect (config, (err, client) => {
     * if (err) throw err
     * // ...
     * client.close ()
     *})
     * /
    if (typeof config.log === 'object') {
      this.log = config.log
    }

    / **
     * @ имя Config # connTimeoutMs
     * @summary Начальное время ожидания соединения с хостом в миллисекундах.
     * @description Клиент соблюдает этот тайм-аут при открытии соединения с
     * кластер впервые.
     * @type {number}
     * @ по умолчанию 1000
     * /
    if (Number.isInteger (config.connTimeoutMs)) {
      this.connTimeoutMs = config.connTimeoutMs
    }

    / **
     * @name Config # loginTimeoutMs
     * Время ожидания входа в узел @summary в миллисекундах.* @type {number}
     * @ по умолчанию 5000
     * /
    if (Number.isInteger (config.loginTimeoutMs)) {
      this.loginTimeoutMs = config.loginTimeoutMs
    }

    / **
     * @name Config # maxSocketIdle
     *
     * @summary Максимальное время простоя сокета в секундах.
     *
     * @description Пулы соединений будут отбрасывать сокеты, которые были простаивающими
     * длиннее максимального. Значение ограничено 24 часами (86400).
     *
     * Важно установить это значение на несколько секунд меньше, чем на сервере.
     *  proto-fd-idle-ms  (по умолчанию 60000 миллисекунд или 1 минута),
     * поэтому клиент не пытается использовать сокет, который уже был
     * пожинается сервером.*
     * Пулы соединений теперь реализуются стеком LIFO. Подключения на
     * хвостовая часть стека всегда используется меньше всего. Эти связи
     * проверяется на  maxSocketIdle  каждые 30 стандартных итераций
     * (обычно 30 секунд).
     *
     * @type {number}
     *
     * @ по умолчанию 55 секунд
     * /
    if (Number.isInteger (config.maxSocketIdle)) {
      this.maxSocketIdle = config.maxSocketIdle
    }

    / **
     * @name Config # TenderInterval
     * @summary Интервал опроса в миллисекундах для кластерного тендера.* @type {number}
     * @ по умолчанию 1000
     * /
    if (Number.isInteger (config.tenderInterval)) {
      this.tenderInterval = config.tenderInterval
    }

    / **
     * @ имя Config # maxConnsPerNode
     *
     * @summary Максимальное количество асинхронных подключений, разрешенных на серверный узел.
     *
     * @description Новые транзакции будут отклонены с пометкой {@link
     * модуль: aerospike / status.ERR_NO_MORE_CONNECTIONS | ERR_NO_MORE_CONNECTIONS}
     * ошибка при превышении лимита.
     *
     * @type {number}
     *
     * @ по умолчанию 300
     * /
    если (Число.isInteger (config.maxConnsPerNode)) {
      this.maxConnsPerNode = config.maxConnsPerNode
    }

    / **
     * @name Config # minConnsPerNode
     *
     * @summary Минимальное количество асинхронных подключений, разрешенных на серверный узел.
     *
     * @description Предварительно распределяет минимальные соединения при создании клиентского узла. В
     * клиент будет периодически выделять новые подключения, если количество падает ниже
     * мин соединений.
     *
     * Сервер  proto-fd-idle-ms  также может нуждаться в увеличении
     * существенно, если определены минимальные соединения.В
     *  proto-fd-idle-ms  по умолчанию указывает серверу закрыть
     * соединения, которые бездействуют в течение 60 секунд, что может нарушить цель
     * сохранение связей в резерве на случай будущего всплеска активности.
     *
     * Если сервер  proto-fd-idle-ms  изменен, клиент {@link
     * Config # maxSocketIdle} также следует изменить на несколько секунд меньше
     * чем  proto-fd-idle-ms .
     *
     * @type {number}
     * @ по умолчанию 0
     * /
    если (Число.isInteger (config.minConnsPerNode)) {
      this.minConnsPerNode = config.minConnsPerNode
    }

    if (typeof config.modlua === 'object') {
      / **
       * @summary Значения конфигурации для пользовательского пути mod-lua.
       * @description Если вы используете пользовательские функции (UDF) для обработки
       * результаты запроса (т.е. агрегации), тогда вам будет полезно установить
       * настройки  modlua . Особое значение имеет
       *  modelua.userPath , который позволяет вам определить путь к которому
       * клиентская библиотека будет искать файлы Lua для обработки.* @type {Object}
       *
       * @property {строка} [modlua.userPath] - Путь к пользовательским скриптам Lua.
       * /
      this.modlua = Object.assign ({}, config.modlua)
    }

    / **
     * @name Config # sharedMemory
     * @summary Конфигурация общей памяти.
     * @description Это позволяет нескольким экземплярам клиентов работать в отдельных
     * процессы на одной машине для обмена статусом кластера, включая узлы и
     * данные карт разделения. Каждый сегмент разделяемой памяти содержит состояние для одного
     * Кластер Aerospike.Если есть несколько кластеров Aerospike, другой
     *  ключ  должен быть определен для каждого кластера.
     * @type {Object}
     * @ см. {@link http://www.aerospike.com/docs/client/c/usage/shm.html#operational-notes| Примечания по эксплуатации}
     * @tutorial node_clusters
     *
     * @property {boolean} [enable = true] - включить / отключить использование
     * Общая память.
     * @property {number} ключ - идентификатор сегмента разделяемой памяти
     * связан с целевым кластером Aerospike; тот же ключ должен быть
     * используется на всех клиентских экземплярах, подключенных к одному кластеру.* @property {number} [maxNodes = 16] - устанавливает макс. количество
     * серверные узлы в кластере - это значение требуется для определения размера общего
     * сегмент памяти. Убедитесь, что вы оставили подушку между фактическим серверным узлом
     * cound и  maxNodes , чтобы вы могли добавлять новые узлы без
     * перезагрузка клиента.
     * @property {number} [maxNamespaces = 8] - устанавливает макс. количество
     * пространства имен, используемые в кластере - это значение требуется для определения размера общего
     * сегмент памяти.Убедитесь, что вы оставляете подушку между фактическим пространством имен
     * count и  maxNamespaces , чтобы можно было добавлять новые пространства имен
     * без перебронирования клиента.
     * @property {number} [takeoverThresholdSeconds = 30] - срок действия
     * время в секундах для блокировки сегмента разделяемой памяти; если кластер
     * статус не был обновлен после этого количества секунд другой клиентский экземпляр
     * возьмет на себя обслуживание кластера с общей памятью.
     *
     * @example  Использование общей памяти в кластерной установке 
     *
     * const Aerospike = require ('aerospike')
     * const cluster = require ('кластер')
     *
     * const config = {
     *   Общая память: {
     * ключ: 0xa5000000
     *}
     *}
     * const client = Aerospike.клиент (конфигурация)
     * const noWorkers = 4
     *
     * if (cluster.isMaster) {
     * // порождаем новые рабочие процессы
     * for (var i = 0; i  {if (err) throw err})
     *
     * // обрабатываем входящие HTTP-запросы и т. д.
     * // http.createServer ((запрос, ответ) => {...})
     *
     * // закрываем соединение с БД при выключении
     * клиент.Закрыть()
     *}
     * /
    if (typeof config.sharedMemory === 'object') {
      this.sharedMemory = config.sharedMemory
    }

    / **
     * @name Config # useAlternateAccessAddress
     * @summary Должен ли клиент использовать сервер
     *  альтернативный-адрес-доступа  вместо
     *  адрес-доступа .
     *
     * @type {логический}
     * @default false
     * @since v3.7.1
     * /
    this.useAlternateAccessAddress = Boolean (config.useAlternateAccessAddress)

    / **
     * @name Config # rackAware
     * @summary Отслеживание данных стойки сервера.* @description Это поле полезно при направлении команд чтения в
     * серверный узел, содержащий ключ и находящийся в той же стойке, что и
     * клиент. Это способствует снижению затрат поставщика облачных услуг, когда узлы
     * распределены по разным стойкам / центрам обработки данных.
     *
     * Конфигурация {@link Config # rackId rackId}, {@link
     * module: aerospike / policy.replica PREFER_RACK} политика реплики и сервер
     * конфигурация стойки также должна быть настроена для включения этой функции.
     *
     * @type {логический}
     * @default false
     * @since 3.8.0
     * /
    this.rackAware = config.rackAware

    / **
     * @ имя Config # RackId
     * @summary Стойка, в которой находится этот клиентский экземпляр.
     * @description {@link Config # rackAware rackAware} config, {@link
     * module: aerospike / policy.replica PREFER_RACK} политика реплики и сервер
     * конфигурация стойки также должна быть настроена для включения этой функции.
     *
     * @type {number}
     * @ по умолчанию 0
     * @since 3.8.0
     * /
    if (Number.isInteger (config.rackId)) {
      this.rackId = config.rackId
    }
  }

  / **
   * Установите политики по умолчанию из заданных значений политики.
   *
   * @param {Config ~ Policies} одна или несколько политик по умолчанию
   * @throws {TypeError}, если какое-либо из свойств объекта политик не
   * действующий тип политики
   * /
  setDefaultPolicies (политики) {
    for (тип const в политике) {
      значения const = политики [тип]
      this.policies [тип] = policy.createPolicy (тип, значения)
    }
  }

  / **
   * Пользовательский инспектор, который маскирует свойство пароля при печати
   * config.*
   * @частный
   * /
  [осмотреть] () {
    const copy = Object.assign ({}, это)
    if (this.password! == undefined) {
      Object.assign (копия, {пароль: '[ФИЛЬТР]'})
    }
    вернуть копию
  }
}

/ **
 * @typedef {Object} Конфигурация ~ Политики
 *
 * @property {ApplyPolicy} apply - Политика применения по умолчанию
 * @property {BatchPolicy} batch - Политика пакетной обработки по умолчанию.
 * @property {InfoPolicy} info - информационная политика по умолчанию.
 * @property {OperatePolicy} operation - Политика работы по умолчанию.
 * @property {ReadPolicy} read - Политика чтения по умолчанию.
 * @property {RemovePolicy} remove - Политика удаления по умолчанию.
 * @property {ScanPolicy} scan - Политика сканирования по умолчанию.
 * запрос @property {QueryPolicy} - политика запросов по умолчанию
 * @property {WritePolicy} write - Политика записи по умолчанию
 * /

модуль.экспорт = Конфигурация

Ноябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
				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

Node js config js: GitHub — lorenwest/node-config: Node.js Application Configuration

Начало работы · Jest

Запуск из командной строки#

Дополнительная конфигурация#

Создание базового файла конфигурации#

С использованием Babel#

С использованием Webpack#

С использованием Parcel#

С использованием TypeScript#

Configuring Jest · Jest

Options#

Defaults#

Reference#

Modes#

Конфигурация | Vue CLI

Глобальная конфигурация CLI

Целевые браузеры

vue.config.js

baseUrl

publicPath

outputDir

assetsDir

indexPath

filenameHashing

pages

lintOnSave

runtimeCompiler

transpileDependencies

productionSourceMap

crossorigin

integrity

configureWebpack

chainWebpack

css.modules

css.requireModuleExtension

css.sourceMap

css.loaderOptions

devServer

devServer.proxy

parallel

pwa

pluginOptions

Babel

ESLint

TypeScript

Модульное тестирование

Jest

Mocha (через

E2E тестирование

Cypress

Nightwatch

WebdriverIO

— npm

Введение

Руководство проекта

Быстрый старт

Статьи

Дополнительная информация

Авторы

Лицензия

Node.

GitHub — lorenwest / node-config: Конфигурация приложения Node.js

Введение

Руководство проекта

Быстрый старт

Статьи

Дополнительная информация

Авторы

Лицензия

Как сохранить локальные данные конфигурации

переменных среды | Gatsby

Доступ к переменным среды в JavaScript

Определение переменных среды

Клиентский JavaScript

Серверный Node.js

Пример использования переменной среды

Зарезервированные переменные среды:

Переменные сборки

Дополнительные среды (промежуточные, тестовые и т. Д.)

Google Analytics env var example