@tony.ganchev/eslint-plugin-header 3.2.3 → 3.2.4

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.
Files changed (3) hide show
  1. package/CONTRIBUTING.md +100 -0
  2. package/README.md +2 -2
  3. package/package.json +3 -2
package/CONTRIBUTING.md ADDED
@@ -0,0 +1,100 @@
1
+ # Contributing to _\@tony.ganchev/eslint-plugin-header_
2
+
3
+ First and foremost, thank you for your interest in contributing to
4
+ _\@tony.ganchev/eslint-plugin-header_! This project was created out of necessity
5
+ by contributors to _eslint-plugin-header_ and as such is driven by the same
6
+ spirit that you display, therefore you are welcome!
7
+
8
+ ## Table of Contents
9
+
10
+ 1. [Table of Contents](#table-of-contents)
11
+ 2. [Prerequisites](#prerequisites)
12
+ 3. [Versioning and Branching Strategy](#versioning-and-branching-strategy)
13
+ 4. [Building](#building)
14
+ 5. [Development](#development)
15
+ 1. [OS Handling](#os-handling)
16
+ 2. [Testing](#testing)
17
+ 6. [Sending a PR](#sending-a-pr)
18
+ 7. [Reaching the Maintainers](#reaching-the-maintainers)
19
+
20
+ ## Prerequisites
21
+
22
+ Before you beg, check out the long and boring
23
+ [code of conduct](./CODE_OF_CONDUCT.md).
24
+
25
+ The project has been developed on Windows and Linux. We assume macOS would work
26
+ just as well.
27
+
28
+ No special setup is needed besides getting the code and a recent version of
29
+ Node.js.
30
+
31
+ ## Versioning and Branching Strategy
32
+
33
+ The project follows semantic versioning as explained in
34
+ [this section](./README.md#versioning) of the docs.
35
+
36
+ There are two product lines as of today:
37
+
38
+ | Product Line | Branch | Dist-tag | Description |
39
+ |--------------|----------|---------------|------------------------------------|
40
+ | v3.2.x | `main` | `latest` | Main product line. |
41
+ | v3.1.x | `v3.1.x` | `maintenance` | Security-related patches. |
42
+
43
+ ## Building
44
+
45
+ After cloning the repository you can try to do a full CI/CD run:
46
+
47
+ ```bash
48
+ $ npm install
49
+ ...
50
+ $ npm run test
51
+ ...
52
+ ```
53
+
54
+ It will run a number of other npm scripts that together verify the code:
55
+
56
+ | script | Description |
57
+ |-----------------|------------------------------------------------------------|
58
+ | `npm run lint` | Lints the source and docs. |
59
+ | `npm run unit` | Runs all mocha unit tests. |
60
+ | `npm run build` | Generates TypeScript bindings. Prerequisite for E2E tests. |
61
+ | `npm run e2e` | Runs E2E smoke tests for all supported versions of ESLint. |
62
+
63
+ ## Development
64
+
65
+ The project uses JSDoc to guarantee some level of type safety and as the source
66
+ for and to generate bindings for projects using TypeScript to do ESLint
67
+ configuration. The `build` script also runs `tsc` type checks on the JavaScript
68
+ sources.
69
+
70
+ We always appreciate the occasional assert that guarantees the invariants at
71
+ runtime without incurring testing overhead.
72
+
73
+ ### OS Handling
74
+
75
+ Whatever the platform chosen is, keep in mind any impact of your
76
+ work on systems with differing line endings. Unit tests provide significant
77
+ coverage for both Windows and POSIX but new corner-cases can always come up.
78
+
79
+ ### Testing
80
+
81
+ We have 100% coverage and would love to stay that way. As with many CLI projects
82
+ we know this can be hard but we are always available to help with the tricky
83
+ bits.
84
+
85
+ If you have specific concerns related to how your change works on older ESLint
86
+ versions especially considering hierarchical configuration format, think about
87
+ adding to the small set of E2E tests.
88
+
89
+ ## Sending a PR
90
+
91
+ Maintainers try to loosely follow the Angular format for writing change
92
+ descriptions. We are not religious about it but it does caress our OCD the right
93
+ way. What is more important is good wording of the change or problem being
94
+ solved and calling out specific intricate details that the reviewer needs to
95
+ keep in mind. Do include the issue number if such exists.
96
+
97
+ ## Reaching the Maintainers
98
+
99
+ Outside of PRs, you can always reach us through the Issues and Discussions
100
+ pages.
package/README.md CHANGED
@@ -74,8 +74,8 @@ The legacy configuration format inherited from
74
74
  supported and you can learn how to use it in a
75
75
  [dedicated document](legacy-config.md). For information on how to switch from
76
76
  the legacy configuration format to the new style, follow our
77
- [migration guide](migrate-config.md). The current document from this point on
78
- will cover only the new configuration format.
77
+ [migration guide](./docs/migrate-config.md). The current document from this
78
+ point on will cover only the new configuration format.
79
79
 
80
80
  This _header_ rule takes a single object as configuration, after the severity
81
81
  level. At the very least, the object should contain a `header` field describing
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tony.ganchev/eslint-plugin-header",
3
- "version": "3.2.3",
3
+ "version": "3.2.4",
4
4
  "description": "The native ESLint 9/10 header plugin. A zero-bloat, drop-in replacement for 'eslint-plugin-header' with first-class Flat Config & TypeScript support. Auto-fix Copyright, License, and banner comments in JavaScrip and TypeScript files.",
5
5
  "main": "index.js",
6
6
  "types": "index.d.ts",
@@ -14,7 +14,8 @@
14
14
  "files": [
15
15
  "lib/**/*.js",
16
16
  "index.d.ts*",
17
- "types"
17
+ "types",
18
+ "CONTRIBUTING.md"
18
19
  ],
19
20
  "scripts": {
20
21
  "build": "npx tsc",