json-merge 1.1.2 → 7.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
data/RUBOCOP.md DELETED
@@ -1,71 +0,0 @@
1
- # RuboCop Usage Guide
2
-
3
- ## Overview
4
-
5
- A tale of two RuboCop plugin gems.
6
-
7
- ### RuboCop Gradual
8
-
9
- This project uses `rubocop_gradual` instead of vanilla RuboCop for code style checking. The `rubocop_gradual` tool allows for gradual adoption of RuboCop rules by tracking violations in a lock file.
10
-
11
- ### RuboCop LTS
12
-
13
- This project uses `rubocop-lts` to ensure, on a best-effort basis, compatibility with Ruby >= 1.9.2.
14
- RuboCop rules are meticulously configured by the `rubocop-lts` family of gems to ensure that a project is compatible with a specific version of Ruby. See: https://rubocop-lts.gitlab.io for more.
15
-
16
- ## Checking RuboCop Violations
17
-
18
- To check for RuboCop violations in this project, always use:
19
-
20
- ```bash
21
- bundle exec rake rubocop_gradual:check
22
- ```
23
-
24
- **Do not use** the standard RuboCop commands like:
25
- - `bundle exec rubocop`
26
- - `rubocop`
27
-
28
- ## Understanding the Lock File
29
-
30
- The `.rubocop_gradual.lock` file tracks all current RuboCop violations in the project. This allows the team to:
31
-
32
- 1. Prevent new violations while gradually fixing existing ones
33
- 2. Track progress on code style improvements
34
- 3. Ensure CI builds don't fail due to pre-existing violations
35
-
36
- ## Common Commands
37
-
38
- - **Check violations**
39
- - `bundle exec rake rubocop_gradual`
40
- - `bundle exec rake rubocop_gradual:check`
41
- - **(Safe) Autocorrect violations, and update lockfile if no new violations**
42
- - `bundle exec rake rubocop_gradual:autocorrect`
43
- - **Force update the lock file (w/o autocorrect) to match violations present in code**
44
- - `bundle exec rake rubocop_gradual:force_update`
45
-
46
- ## Workflow
47
-
48
- 1. Before submitting a PR, run `bundle exec rake rubocop_gradual:autocorrect`
49
- a. or just the default `bundle exec rake`, as autocorrection is a pre-requisite of the default task.
50
- 2. If there are new violations, either:
51
- - Fix them in your code
52
- - Run `bundle exec rake rubocop_gradual:force_update` to update the lock file (only for violations you can't fix immediately)
53
- 3. Commit the updated `.rubocop_gradual.lock` file along with your changes
54
-
55
- ## Never add inline RuboCop disables
56
-
57
- Do not add inline `rubocop:disable` / `rubocop:enable` comments anywhere in the codebase (including specs, except when following the few existing `rubocop:disable` patterns for a rule already being disabled elsewhere in the code). We handle exceptions in two supported ways:
58
-
59
- - Permanent/structural exceptions: prefer adjusting the RuboCop configuration (e.g., in `.rubocop.yml`) to exclude a rule for a path or file pattern when it makes sense project-wide.
60
- - Temporary exceptions while improving code: record the current violations in `.rubocop_gradual.lock` via the gradual workflow:
61
- - `bundle exec rake rubocop_gradual:autocorrect` (preferred; will autocorrect what it can and update the lock only if no new violations were introduced)
62
- - If needed, `bundle exec rake rubocop_gradual:force_update` (as a last resort when you cannot fix the newly reported violations immediately)
63
-
64
- In general, treat the rules as guidance to follow; fix violations rather than ignore them. For example, RSpec conventions in this project expect `described_class` to be used in specs that target a specific class under test.
65
-
66
- ## Benefits of rubocop_gradual
67
-
68
- - Allows incremental adoption of code style rules
69
- - Prevents CI failures due to pre-existing violations
70
- - Provides a clear record of code style debt
71
- - Enables focused efforts on improving code quality over time
data/SECURITY.md DELETED
@@ -1,21 +0,0 @@
1
- # Security Policy
2
-
3
- ## Supported Versions
4
-
5
- | Version | Supported |
6
- |----------|-----------|
7
- | 1.latest | ✅ |
8
-
9
- ## Security contact information
10
-
11
- To report a security vulnerability, please use the
12
- [Tidelift security contact](https://tidelift.com/security).
13
- Tidelift will coordinate the fix and disclosure.
14
-
15
- ## Additional Support
16
-
17
- If you are interested in support for versions older than the latest release,
18
- please consider sponsoring the project / maintainer @ https://liberapay.com/pboling/donate,
19
- or find other sponsorship links in the [README].
20
-
21
- [README]: README.md