Configuration
Welcome to the comprehensive configuration guide for Sec5, your trusted workspace security tool. This document equips you with the knowledge required to tailor Sec5's behavior to your project's specific needs. By configuring Sec5 effectively, you can enforce critical security and best practices across your codebase, fostering a well-maintained and secure development environment.
Configuration Files
Sec5 exhibits flexibility in terms of configuration file names. Here's the list of supported filenames, presented in hierarchical order (where the highest name takes precedence if duplicated):
sec5.config.js
sec.config.js
secure.config.js
sec5.js
sec.js
secure.js
Default Configuration
For scenarios where no explicit configuration file is present, Sec5 employs a set of default settings. Let's explore them in detail:
export default {
allowComments: false, // Disallow comments like FIXME, BUG in the codebase by default.
allowNonWritedChangelog: false, // Enforce corresponding changelog entries for code changes.
allowNoVersion: false, // Require a version number in package.json.
allowNoFormat: false, // Enforce code formatting via tools like Prettier.
allowNoLint: false, // Enforce linting rules.
ignoredChecks: [] // Empty array, implying all checks are enabled.
}
Configuration Options: A Deeper Dive
Now, let's delve into each configuration option and understand its - impact on Sec5's behavior:
1. allowComments
(Default: false)
- Purpose: Governs whether comments are permitted in your codebase.
- Impact:
false:
Sec5 flags any comments encountered during its analysis. Enforcing a comment-free codebase might not be ideal for all projects. Consider using code reviews or documentation tools for comment management.true:
Sec5 allows comments in the code.
2. allowNonWritedChangelog
(Default: false)
- Purpose: Controls whether code changes must be documented within a CHANGELOG.md file.
- Impact:
false:
Sec5 strictly enforces the presence of a corresponding CHANGELOG entry for every code modification. This ensures clear change history and traceability.true:
Sec5 doesn't mandate updates to the CHANGELOG for code changes. However, maintaining a changelog is highly recommended for version control and communication - purposes.
3. allowNoVersion
(Default: false)
- Purpose: Dictates whether a version number is compulsory within the package.json file.
- Impact:
false:
Sec5 necessitates a version number to be defined in package.json. Version numbers are crucial for project release management and dependency management.true:
Sec5 doesn't necessitate a version number, but having one is generally considered good practice.
4. allowNoFormat
(Default: false)
- Purpose: Controls whether code formatting using tools like Prettier is mandatory.
- Impact:
false:
Sec5 enforces code formatting consistency through tools like Prettier. Consistent formatting improves code readability and maintainability.true:
Sec5 allows for non-formatted code. However, using a code formatter is recommended to ensure a clean and consistent codebase.
5. allowNoLint
(Default: false)
- Purpose: Dictates whether adherence to linting rules is mandatory.
- Impact:
false:
Sec5 enforces established linting rules to identify potential code issues and style inconsistencies. Linting improves code quality and reduces errors.true:
Sec5 allows for code that might not comply with linting rules. However, using a linter is highly recommended to detect coding best practice violations.
6. ignoredChecks
(Default: [])
- Purpose: Allows you to selectively ignore specific Sec5 checks.
- Impact: You can specify an array of check names (e.g., ['comment', 'eslint']) to exclude them from Sec5's analysis. Use this option cautiously, as ignoring checks might introduce security vulnerabilities or inconsistencies. Here are the supported check names:
'comment'
: Disables comment checks.'changelog'
: Disables changelog checks.'version'
: Disables version checks.'prettier'
: Disables Prettier checks.'eslint'
: Disables Eslint checks.