@peerigon/configs 1.0.0-beta.17 → 1.0.0-beta.18

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.
package/CHANGELOG.md CHANGED
@@ -1,3 +1,9 @@
1
+ # [1.0.0-beta.18](https://github.com/peerigon/configs/compare/v1.0.0-beta.17...v1.0.0-beta.18) (2025-01-26)
2
+
3
+ ### Features
4
+
5
+ - Add docs ([83e7f61](https://github.com/peerigon/configs/commit/83e7f617d6fc44abcd7e0d05c700299d8e2910c2))
6
+
1
7
  # [1.0.0-beta.17](https://github.com/peerigon/configs/compare/v1.0.0-beta.16...v1.0.0-beta.17) (2025-01-20)
2
8
 
3
9
  ### Bug Fixes
package/README.md CHANGED
@@ -1,451 +1,63 @@
1
- # eslint-config-peerigon
1
+ # configs
2
2
 
3
- **[Peerigon](https://peerigon.com/) coding rules as [ESLint](http://eslint.org/) config.**
3
+ **Best practice configs for [ESLint](https://eslint.org/), [Prettier](https://prettier.io/), [TypeScript](https://www.typescriptlang.org/) & friends. By [Peerigon](https://www.peerigon.com/).**
4
4
 
5
- [![Version on NPM](https://img.shields.io/npm/v/eslint-config-peerigon?style=for-the-badge)](https://www.npmjs.com/package/eslint-config-peerigon)
5
+ [![Version on NPM](https://img.shields.io/npm/v/@peerigon/configs?style=for-the-badge)](https://www.npmjs.com/package/@peerigon/configs)
6
6
  [![Semantically released](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg?style=for-the-badge)](https://github.com/semantic-release/semantic-release)
7
- [![Monthly downloads on NPM](https://img.shields.io/npm/dm/eslint-config-peerigon?style=for-the-badge)](https://www.npmjs.com/package/eslint-config-peerigon)<br>
8
- [![License](https://img.shields.io/npm/l/eslint-config-peerigon?style=for-the-badge)](./LICENSE)
7
+ [![Monthly downloads on NPM](https://img.shields.io/npm/dm/@peerigon/configs?style=for-the-badge)](https://www.npmjs.com/package/@peerigon/configs)<br>
8
+ [![License](https://img.shields.io/npm/l/@peerigon/configs?style=for-the-badge)](./LICENSE)
9
9
 
10
- Linting and formatting rules are always a balance between
10
+ This package contains best practice configs and rules for linting, type-checking, formatting and publishing JavaScript and TypeScript code. Use them to kickstart you next awesome web project 🚀!
11
11
 
12
- - ease of reading
13
- - ease of refactoring
14
- - ease of writing.
12
+ ## Installation
15
13
 
16
- We think that
17
-
18
- - code is read more often than refactored
19
- - and refactored more often than written from scratch.
20
-
21
- Our linting rules have been designed with these assumptions in mind.
22
-
23
- ## Table of contents
24
-
25
- - [Quick start](#quick-start)
26
- - [Practical guide](#practical-guide)
27
- - [Provided configs](#provided-configs)
28
- - [Styles](#styles)
29
-
30
- ## Quick start
31
-
32
- Recommended configuration in your `package.json`:
33
-
34
- ```js
35
- {
36
- "scripts": {
37
- "test:lint": "eslint --max-warnings 0 --cache",
38
- "posttest": "npm run test:lint"
39
- }
40
- }
41
- ```
42
-
43
- We also offer a [Prettier](https://prettier.io/) config that matches our ESLint config. Create a `.prettierrc.json` in your project with the following content:
44
-
45
- ```json
46
- "eslint-config-peerigon/prettier.config.js"
47
- ```
48
-
49
- There are presets for the most common setups:
50
-
51
- ### TypeScript
52
-
53
- ```
54
- npm i eslint eslint-config-peerigon --save-dev
55
- ```
56
-
57
- ```js
58
- {
59
- "extends": [
60
- "peerigon/presets/typescript.js"
61
- ],
62
- "env": {
63
- "node": true
64
- },
65
- "root": true
66
- }
67
- ```
68
-
69
- ### TypeScript + React
70
-
71
- ```
72
- npm i eslint eslint-config-peerigon eslint-plugin-react eslint-plugin-jsx-a11y eslint-plugin-react-hooks --save-dev
73
- ```
74
-
75
- ```js
76
- {
77
- "extends": [
78
- "peerigon/presets/typescript-react.js"
79
- ],
80
- "env": {
81
- "node": true,
82
- "browser": true
83
- },
84
- "root": true
85
- }
86
- ```
87
-
88
- ### TypeScript + Node
89
-
90
- ```
91
- npm i eslint eslint-config-peerigon eslint-plugin-n --save-dev
92
- ```
93
-
94
- ```js
95
- {
96
- "extends": [
97
- "peerigon/presets/typescript-node.js"
98
- ],
99
- "root": true
100
- }
101
- ```
102
-
103
- ## Practical guide
104
-
105
- ### Disabling rules
106
-
107
- Try to disable as less rules as possible. In most cases it's best to just write
108
-
109
- ```js
110
- // eslint-disable-next-line [rule-code]
111
- ```
112
-
113
- where `[rule-code]` is the code that is displayed along the error message. Disabling the next line is usually better because it resists [Prettier](https://prettier.io/) reformatting.
114
-
115
- Sometimes it makes sense to disable a rule within a specifc file. In that case you can put the following snippet at the beginning of the file:
116
-
117
- ```js
118
- /* eslint-disable [rule-code] */
119
- ```
120
-
121
- If you don't agree with a rule, please do not just disable the rule. Often there are good reasons and the current setting is the result of years of experience. It's better to create an issue here to start a discussion about the pros and cons of a rule.
122
-
123
- ### Different styles
124
-
125
- We acknowledge that there are certain rules where there are no actual pros and cons or where there is no clear winner. You just have to decide for one style and stick with it. We also know that some rules make sense in one project, but don't make sense in another project. That's why we also provide a list of [accepted custom styles](#styles) (see also [this discussion](https://github.com/peerigon/eslint-config-peerigon/issues/11)) which you can pick.
126
-
127
- ### VSCode
128
-
129
- This is our recommended VSCode configuration using the [Prettier extension](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode). Adjust it to the needs of your particular project:
130
-
131
- ```json
132
- {
133
- "editor.defaultFormatter": "esbenp.prettier-vscode",
134
- "editor.formatOnSave": true,
135
- "editor.codeActionsOnSave": {
136
- "source.fixAll.eslint": true
137
- }
138
- }
139
- ```
140
-
141
- ### Experimental syntax using Babel
142
-
143
- If you're using Babel you should set [`requireConfigFile: true`](https://github.com/babel/babel/tree/main/eslint/babel-eslint-parser#additional-parser-configuration) in your ESLint config. ESLint will then use your `babel.config.json`.
144
-
145
- ```js
146
- {
147
- "parserOptions": { "requireConfigFile": true },
148
- }
149
- ```
150
-
151
- ### Naming conventions for properties
152
-
153
- Sometimes we're not in full control over the naming conventions in our codebase, for instance if data is coming from a foreign API. While it often is preferable to transform property names into camelCase, it might not be practical. In these situations you can disable the check for properties like this:
154
-
155
- ```js
156
- const options = require("eslint-config-peerigon/options.js");
157
-
158
- module.exports = {
159
- /* ... */
160
- rules: {
161
- // The API uses snake_case as properties
162
- camelcase: [
163
- "warn",
164
- {
165
- ...options["camelcase"],
166
- properties: "never",
167
- },
168
- ],
169
- },
170
- };
171
- ```
172
-
173
- **In TypeScript projects:**
174
-
175
- ```js
176
- const options = require("eslint-config-peerigon/options.js");
177
-
178
- module.exports = {
179
- /* ... */
180
- rules: {
181
- // The API uses snake_case as properties
182
- "@typescript-eslint/naming-convention": [
183
- "warn",
184
- options["@typescript-eslint/naming-convention"].ignoreProperties,
185
- ...options["@typescript-eslint/naming-convention"].defaultRules,
186
- ],
187
- },
188
- };
189
- ```
190
-
191
- ## Provided configs
192
-
193
- ### [`peerigon`](base.js)
194
-
195
- **Base rules for every project. You should always add these rules.**
196
-
197
- ```
198
- npm i eslint eslint-config-peerigon --save-dev
199
- ```
200
-
201
- These rules assume a modern project with full ES2015 support, including ES modules. For specific environments like Node.js or old JS engines, see below. The base rules do not define an `env`, so you might want to do that for yourself to enable specific globals.
202
-
203
- Add an `.eslintrc.json` to the project's root folder:
204
-
205
- ```js
206
- {
207
- "extends": [
208
- // Base rules for every project
209
- "peerigon"
210
- ],
211
- // Do not search for further eslint configs in upper directories
212
- "root": true,
213
- // If you're using Babel, you should set requireConfigFile: true
214
- // ESLint will then use your babel.config.json.
215
- // "parserOptions": { "requireConfigFile": true },
216
- }
217
- ```
218
-
219
- The base rules use the `eslint-plugin-import` to resolve imports. Although it's possible to define [custom resolvers](https://github.com/benmosher/eslint-plugin-import#resolvers), it's highly discouraged to deviate from the common Node.js resolving algorithm. Other tools like linters and intellisense don't work reliably when you change the resolver.
220
-
221
- ### [`peerigon/typescript`](typescript.js)
222
-
223
- Rules for [TypeScript](https://www.typescriptlang.org/).
224
-
225
- ```js
226
- {
227
- "extends": [
228
- "peerigon",
229
- "peerigon/typescript",
230
- // Arrow functions are preferred with TypeScript
231
- // See https://github.com/peerigon/eslint-config-peerigon/issues/23#issuecomment-472614432
232
- "peerigon/styles/prefer-arrow"
233
- ],
234
- "root": true,
235
- }
236
- ```
237
-
238
- You need to add `--ext js,jsx,cjs,mjs,ts,tsx` to the `test:lint` script:
239
-
240
- ```js
241
- {
242
- "scripts": {
243
- "test:lint": "eslint --max-warnings 0 --cache --ext js,jsx,cjs,mjs,ts,tsx --ignore-path .gitignore ."
244
- }
245
- }
246
- ```
247
-
248
- _We recommend using [`peerigon/styles/prefer-arrow`](#peerigonstylesprefer-arrow) because arrow functions (or function expressions in general) can leverage [TypeScript's contextual typing](https://www.typescriptlang.org/docs/handbook/type-inference.html#contextual-typing)._
249
-
250
- ### [`peerigon/node`](node.js)
251
-
252
- **Important: Requires [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).**
253
-
254
- ```
255
- npm i eslint-plugin-n --save-dev
256
- ```
257
-
258
- ```js
259
- {
260
- "extends": [
261
- "peerigon",
262
- "peerigon/node"
263
- ],
264
- // Setting env.node = true is not necessary, this is already done by peerigon/node
265
- "root": true
266
- }
267
- ```
268
-
269
- ### [`peerigon/react`](react.js)
270
-
271
- **Important: Requires [`eslint-plugin-react`](https://github.com/yannickcr/eslint-plugin-react), [`eslint-plugin-jsx-a11y`](https://github.com/evcohen/eslint-plugin-jsx-a11y) and [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks) as project dependency.**
272
-
273
- ```
274
- npm i eslint-plugin-react eslint-plugin-jsx-a11y eslint-plugin-react-hooks --save-dev
275
- ```
276
-
277
- Rules for [React](https://facebook.github.io/react/) development, including accessibility rules.
278
- These rules are also applicable in other JSX environments, like [Preact](https://github.com/developit/preact):
279
-
280
- ```js
281
- {
282
- "extends": [
283
- "peerigon",
284
- "peerigon/react"
285
- ],
286
- "root": true
287
- }
288
- ```
289
-
290
- _We recommend using [`peerigon/styles/react-jsx-no-literals`](#peerigonstylesreact-jsx-no-literals) if you're using i18n in your project._
291
- _You can use [`peerigon/styles/react-jsx-no-bind`](#peerigonstylesreact-jsx-no-bind) if you're using `memo` and `shouldComponentUpdate` a lot._
292
-
293
- ### [`peerigon/jsdoc`](jsdoc.js)
294
-
295
- **Important: Requires [`eslint-plugin-jsdoc`](https://github.com/gajus/eslint-plugin-jsdoc) as project dependency.**
296
-
297
- ```
298
- npm i eslint-plugin-jsdoc --save-dev
299
- ```
300
-
301
- Makes sure that JSDoc annotations are written in a standard-compliant and uniform way.
302
-
303
- ```js
304
- {
305
- "extends": [
306
- "peerigon",
307
- "peerigon/jsdoc"
308
- ],
309
- "root": true
310
- }
311
- ```
312
-
313
- ## Styles
314
-
315
- The following rules enable specific writing styles. Use them as you prefer.
316
-
317
- ### [`peerigon/styles/prefer-arrow`](styles/prefer-arrow.js)
318
-
319
- Enforces arrow function expressions instead of function declarations (see [#23](https://github.com/peerigon/eslint-config-peerigon/issues/23)).
320
- Regular functions are still allowed as methods in objects or classes.
321
-
322
- ```js
323
- "extends": [
324
- "peerigon",
325
- "peerigon/styles/prefer-arrow"
326
- ],
327
- ```
328
-
329
- ### [`peerigon/styles/no-default-export`](styles/no-default-export.js)
330
-
331
- Forbids usage of `export default`. When using default exports, it becomes harder to name classes or functions consistently throughout the codebase since every module can pick its own name for the imported thing. Nicholas C. Zakas, the creator of ESLint, wrote [an article with more compelling arguments why he stopped using `export default`](https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/).
332
-
333
- ```js
334
- "extends": [
335
- "peerigon",
336
- "peerigon/styles/no-default-export"
337
- ],
338
- ```
339
-
340
- **Please note:** This rule is disabled in `.jsx` and `.tsx` files because React components are usually exported via `export default`. [`React.lazy`](https://reactjs.org/docs/code-splitting.html#reactlazy) even expects the lazy loaded component to be exported as `default`.
341
-
342
- ### [`peerigon/styles/no-null`](styles/no-null.js)
343
-
344
- **Important: Requires [`eslint-plugin-no-null`](https://github.com/nene/eslint-plugin-no-null) as project dependency.**
345
-
346
- ```
347
- npm i eslint-plugin-no-null --save-dev
14
+ ```sh
15
+ npm install @peerigon/configs
348
16
  ```
349
17
 
350
- Forbids the usage of `null`. In a codebase it's often better to use a single non-value to represent _the absence of a value_. With the rise of default parameters and destructuring defaults, JavaScript developed a clear tendency towards `undefined`. [This issue](https://github.com/peerigon/eslint-config-peerigon/issues/71) summarizes the arguments (and trade-offs) of **null vs. undefined**.
18
+ Also checkout the instructions for each respective config:
351
19
 
352
- ```js
353
- "extends": [
354
- "peerigon",
355
- "peerigon/styles/no-null"
356
- ],
357
- ```
20
+ - [ESLint](/eslint/README.md)
21
+ - [Prettier](/prettier/README.md)
22
+ - [TypeScript](/typescript/README.md)
23
+ - [Semantic release](/semantic-release/README.md)
358
24
 
359
- **Please note:** If you use this rule, you will probably still need a single `null` value which you can refer to whenever you need to use `null` because of third-party code:
25
+ ## Philosophy
360
26
 
361
- ```js
362
- // eslint-disable-next-line no-null/no-null
363
- export const NULL = null;
364
- ```
27
+ Our rules aim to prevent as many bugs and security vulnerabilities as possible and make refactoring easier. At the same time, they should stay out of the way as much as possible.
365
28
 
366
- ### [`peerigon/styles/prefer-interface`](styles/prefer-interface.js)
29
+ ### Formatting
367
30
 
368
- **Important: Use it in combination with [`peerigon/typescript`](typescript.js).**
31
+ Formatting should follow the community standard. Our config is entirely based on Prettier's default config. Besides that, it also:
369
32
 
370
- [Prefer `interface` over `type`](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/prefer-interface.md).
33
+ - auto-sorts `import` statements
34
+ - formats JSDoc comments
35
+ - formats `package.json`
36
+ - formats and sorts CSS properties
37
+ - sorts Tailwind CSS class names
371
38
 
372
- ```js
373
- "extends": [
374
- "peerigon",
375
- "peerigon/typescript",
376
- "peerigon/styles/prefer-interface"
377
- ],
378
- ```
379
-
380
- ### [`peerigon/styles/react-jsx-no-bind`](styles/react-jsx-no-bind.js)
39
+ ### Linting
381
40
 
382
- **Important: Use it in combination with [`peerigon/react`](react.js).**
41
+ Linting should mostly catch bugs in the control flow and prevent security issues. Furthermore, it should enforce a modern, idiomatic and consistent code style that is easy to read and to refactor.
383
42
 
384
- Depending on the way you write your components, it might be not ok to create functions during `render()`. Use it if you're using things like `React.memo()` or `shouldComponentUpdate` a lot.
43
+ However, it should **not** nit-pick on formatting or favor certain language features where other options are equally ok. Every rule must be legitimized by objective criteria. A simple “I find it easier to read” is not enough.
385
44
 
386
- ```js
387
- "extends": [
388
- "peerigon",
389
- "peerigon/react",
390
- "peerigon/styles/react-jsx-no-bind"
391
- ],
392
- ```
45
+ Our linting rules:
393
46
 
394
- ### [`peerigon/styles/react-jsx-no-literals`](styles/react-jsx-no-literals.js)
47
+ - are mostly based on recommended sets
48
+ - use type information to catch logic bugs
49
+ - highlight a11y problems
50
+ - are less strict in tests
395
51
 
396
- **Important: Use it in combination with [`peerigon/react`](react.js).**
52
+ ### Type-checking
397
53
 
398
- Use this style if you're using i18n. It prevents people from putting raw strings in components.
54
+ Type-checking should be rather strict because it is the foundation for safe and sound refactorings. If type-checking is too loose, it may lull the developer into a false sense of security. It should also prevent out-of-bounds errors when accessing arrays or objects.
399
55
 
400
- ```js
401
- "extends": [
402
- "peerigon",
403
- "peerigon/react",
404
- "peerigon/styles/react-jsx-no-literals"
405
- ],
406
- ```
407
-
408
- It disallows this:
409
-
410
- ```jsx
411
- const Hello = <div>test</div>;
412
- ```
413
-
414
- As an escape hatch, this is still allowed:
415
-
416
- ```jsx
417
- const Hello = <div>{"test"}</div>;
418
- ```
419
-
420
- ### [`peerigon/styles/prefer-array-shorthand`](styles/prefer-array-shorthand.js)
421
-
422
- **Important: Use it in combination with [`peerigon/typescript`](typescript.js).**
423
-
424
- Enforces typescript arrays to use the shorthand array-style instead of the generic style.
425
-
426
- ```js
427
- "extends": [
428
- "peerigon",
429
- "peerigon/typescript",
430
- "peerigon/styles/prefer-array-shorthand"
431
- ],
432
- ```
433
-
434
- It enforces this:
435
-
436
- ```ts
437
- const foo: string[] = [];
438
- ```
439
-
440
- instead of
441
-
442
- ```ts
443
- const foo: Array<string> = [];
444
- ```
56
+ For highly dynamic code or incompatible types, local exceptions to type safety and escape hatches need to be possible.
445
57
 
446
58
  ## License
447
59
 
448
- Unlicense
60
+ MIT
449
61
 
450
62
  ## Sponsors
451
63
 
@@ -0,0 +1,114 @@
1
+ # [ESLint](https://eslint.org/) config
2
+
3
+ ## Installation
4
+
5
+ ```sh
6
+ npm install @peerigon/configs
7
+ ```
8
+
9
+ Then create a `eslint.config.js` next to your `package.json`:
10
+
11
+ ```js
12
+ // We have a couple of presets for popular setups, such as typescript-react or typescript-node
13
+ // See "Presets"
14
+ import typescriptNodePreset from "@peerigon/configs/eslint/presets/typescript-node";
15
+ // You can also choose from a bunch of optional coding styles
16
+ // See "Styles"
17
+ import stylesNoDefaultExport from "@peerigon/configs/eslint/styles/no-default-export";
18
+
19
+ export default [
20
+ ...typescriptNodePreset,
21
+ // The idiomatic way to disable rules in certain directories in ESLint>=9.x is
22
+ // to map() over them and add `ignores` to the rule objects
23
+ ...stylesNoDefaultExport.map((config) => ({
24
+ ...config,
25
+ ignores: [...(config.ignores ?? []), "src/some/folder/*.ts"],
26
+ })),
27
+ ];
28
+ ```
29
+
30
+ Recommended configuration in your `package.json` (using [`npm-run-all`](https://www.npmjs.com/package/npm-run-all)):
31
+
32
+ ```json
33
+ {
34
+ "type": "module",
35
+ "scripts": {
36
+ "test": "run-p test:*",
37
+ "test:lint": "eslint --max-warnings 0 --cache ."
38
+ }
39
+ }
40
+ ```
41
+
42
+ ## Presets
43
+
44
+ Presets bundle all relevant rules into one `import`. They can be imported as `@peerigon/configs/eslint/presets/<preset-name>`. They **should not** be combined with each other.
45
+
46
+ - `typescript-react`: Rules for React projects written in TypeScript
47
+ - `typescript-node`: Rules for TypeScript apps that are supposed to run in Node.js
48
+ - `typescript`: Rules for all other TypeScript projects
49
+ - `javascript-browser`: Rules for JavaScript apps running in a browser (e.g. in combination with JSDoc type annotations)
50
+ - `javascript-node`: Rules for JavaScript apps running in Node.js
51
+ - `javascript`: Rules for all other JavaScript projects
52
+
53
+ ## Styles
54
+
55
+ We acknowledge that there are certain rules where there are no actual pros and cons or where there is no clear winner. You just have to decide for one style and stick with it. We also know that some rules make sense in one project, but don't make sense in another project. Pick these rules if they make sense for you in your project. They can be imported as `@peerigon/configs/eslint/styles/<style-name>`.
56
+
57
+ ### `no-default-export`
58
+
59
+ Forbids usage of `export default`. When using default exports, it becomes harder to name classes or functions consistently throughout the codebase since every module can pick its own name for the imported thing. Nicholas C. Zakas, the creator of ESLint, wrote [an article with more compelling arguments why he stopped using `export default`](https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/).
60
+
61
+ You may want to disable this rule in situations where a default export is required, for instance when using [React's `lazy()`](https://react.dev/reference/react/lazy).
62
+
63
+ ### `no-null`
64
+
65
+ Forbids the usage of `null`. In a codebase it's often better to use a single non-value to represent _the absence of a value_. With the rise of default parameters and destructuring defaults, JavaScript developed a clear tendency towards `undefined`. [This issue](https://github.com/peerigon/eslint-config-peerigon/issues/71) summarizes the arguments (and trade-offs) of **null vs. undefined**.
66
+
67
+ **👉 Hint:** If you use this rule, you will probably still need a single `null` value which you can refer to whenever you need to use `null` because of third-party code:
68
+
69
+ ```js
70
+ // eslint-disable-next-line no-null/no-null
71
+ export const NULL = null;
72
+ ```
73
+
74
+ ### `prefer-interface`
75
+
76
+ [Prefer TypeScript's `interface` over `type`](https://typescript-eslint.io/rules/consistent-type-definitions/).
77
+
78
+ ```js
79
+ "extends": [
80
+ "peerigon",
81
+ "peerigon/typescript",
82
+ "peerigon/styles/prefer-interface"
83
+ ],
84
+ ```
85
+
86
+ ### `prefer-array-shorthand`
87
+
88
+ Enforces TypeScript arrays to use the shorthand array-style instead of the generic style.
89
+ It enforces this:
90
+
91
+ ```ts
92
+ const foo: string[] = [];
93
+ ```
94
+
95
+ instead of
96
+
97
+ ```ts
98
+ const foo: Array<string> = [];
99
+ ```
100
+
101
+ ### `jsx-no-literals`
102
+
103
+ Use this style if you're using i18n. It prevents people from putting raw strings in components.
104
+ It disallows this:
105
+
106
+ ```jsx
107
+ const Hello = <div>test</div>;
108
+ ```
109
+
110
+ As an escape hatch, this is still allowed:
111
+
112
+ ```jsx
113
+ const Hello = <div>{"test"}</div>;
114
+ ```
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@peerigon/configs",
3
- "version": "1.0.0-beta.17",
3
+ "version": "1.0.0-beta.18",
4
4
  "description": "Configs for ESLint, Prettier, TypeScript & friends",
5
5
  "keywords": [
6
6
  "eslint",
@@ -73,6 +73,10 @@
73
73
  "types": "./types/semantic-release/base.d.ts",
74
74
  "default": "./semantic-release/base.js"
75
75
  },
76
+ "./semantic-release/cross-publish": {
77
+ "types": "./types/semantic-release/cross-publish.d.ts",
78
+ "default": "./semantic-release/cross-publish.js"
79
+ },
76
80
  "./typescript": {
77
81
  "default": "./typescript/base.json"
78
82
  },
@@ -162,6 +166,7 @@
162
166
  "typescript": "^5.6.3"
163
167
  },
164
168
  "publishConfig": {
165
- "access": "public"
169
+ "access": "public",
170
+ "provenance": true
166
171
  }
167
172
  }
@@ -0,0 +1,35 @@
1
+ # [Prettier](https://prettier.io/) config
2
+
3
+ ## Installation
4
+
5
+ ```sh
6
+ npm install @peerigon/configs
7
+ ```
8
+
9
+ Then create a `prettier.config.js` next to your `package.json`:
10
+
11
+ ```js
12
+ export { default } from "@peerigon/configs/prettier";
13
+ ```
14
+
15
+ Recommended configuration in your `package.json` (using [`npm-run-all`](https://www.npmjs.com/package/npm-run-all)):
16
+
17
+ ```json
18
+ {
19
+ "type": "module",
20
+ "scripts": {
21
+ "test": "run-p test:*",
22
+ "test:format": "prettier --check ."
23
+ }
24
+ }
25
+ ```
26
+
27
+ ## Configuration
28
+
29
+ Our config is entirely based on Prettier's default config. Besides that, it also:
30
+
31
+ - auto-sorts `import` statements
32
+ - formats JSDoc comments
33
+ - formats `package.json`
34
+ - formats and sorts CSS properties
35
+ - sorts Tailwind CSS class names
@@ -0,0 +1,75 @@
1
+ # [Semantic release](https://semantic-release.gitbook.io/) config
2
+
3
+ ## Installation
4
+
5
+ ```sh
6
+ npm install @peerigon/configs
7
+ ```
8
+
9
+ Then create a `.releaserc.json` next to your `package.json`:
10
+
11
+ ```json
12
+ {
13
+ "extends": "@peerigon/configs/semantic-release"
14
+ }
15
+ ```
16
+
17
+ Recommended configuration in your `package.json`:
18
+
19
+ ```json
20
+ {
21
+ "type": "module",
22
+ "scripts": {
23
+ "release": "semantic-release"
24
+ },
25
+ "publishConfig": {
26
+ "access": "public", // only if the package is supposed to be public
27
+ "provenance": true
28
+ }
29
+ }
30
+ ```
31
+
32
+ Recommended Github action:
33
+
34
+ ```yaml
35
+ name: 🧪 Test and 🚀 Release
36
+
37
+ on:
38
+ push:
39
+ branches:
40
+ - main
41
+ - beta
42
+ pull_request: {}
43
+
44
+ jobs:
45
+ test-and-release:
46
+ runs-on: ubuntu-latest
47
+ if: "!contains(github.event.head_commit.message, '[skip ci]')"
48
+
49
+ permissions:
50
+ # Necessary for semantic-release
51
+ contents: write
52
+ issues: write
53
+ pull-requests: write
54
+ # Necessary for npm publish --provenance
55
+ # See https://docs.npmjs.com/generating-provenance-statements#example-github-actions-workflow
56
+ id-token: write
57
+
58
+ steps:
59
+ # ...
60
+ # Install and build steps
61
+ # ...
62
+ - name: 🚀 Release
63
+ env:
64
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
65
+ NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
66
+ run: |
67
+ npm run release
68
+ ```
69
+
70
+ ## Configuration
71
+
72
+ We export the following `.releaserc.json` presets. They can be used by extending `@peerigon/configs/<preset-name>`:
73
+
74
+ - `semantic-release`: Recommended config for publishing a library to a single registry (according to your `.npmrc`).
75
+ - `semantic-release/cross-publish`: Config for publishing a library both to NPM _and_ Github
@@ -29,17 +29,6 @@ export const config = {
29
29
  assets: ".semantic-release/*.tgz",
30
30
  },
31
31
  ],
32
- [
33
- "@semantic-release/exec",
34
- {
35
- verifyConditionsCmd:
36
- 'echo "registry=https://npm.pkg.github.com/\n//npm.pkg.github.com/:_authToken=${process.env.GITHUB_TOKEN}" > /tmp/github.npmrc && npm whoami --userconfig /tmp/github.npmrc',
37
- publishCmd:
38
- "npm publish --userconfig /tmp/github.npmrc --tag ${nextRelease.channel} --no-git-tag-version",
39
- successCmd: "rm /tmp/github.npmrc",
40
- failCmd: "rm /tmp/github.npmrc",
41
- },
42
- ],
43
32
  ],
44
33
  };
45
34
 
@@ -0,0 +1,22 @@
1
+ import { config as baseConfig } from "./base.js";
2
+
3
+ /** @type {import("semantic-release").Options} */
4
+ export const config = {
5
+ ...baseConfig,
6
+ plugins: [
7
+ ...(baseConfig.plugins ?? []),
8
+ [
9
+ "@semantic-release/exec",
10
+ {
11
+ verifyConditionsCmd:
12
+ 'echo "registry=https://npm.pkg.github.com/\n//npm.pkg.github.com/:_authToken=${process.env.GITHUB_TOKEN}" > /tmp/github.npmrc && npm whoami --userconfig /tmp/github.npmrc',
13
+ publishCmd:
14
+ "npm publish --userconfig /tmp/github.npmrc --tag ${nextRelease.channel} --no-git-tag-version",
15
+ successCmd: "rm /tmp/github.npmrc",
16
+ failCmd: "rm /tmp/github.npmrc",
17
+ },
18
+ ],
19
+ ],
20
+ };
21
+
22
+ export default config;
@@ -1 +1 @@
1
- {"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../semantic-release/base.js"],"names":[],"mappings":"AAAA,iDAAiD;AACjD,qBADW,OAAO,kBAAkB,EAAE,OAAO,CA2C3C"}
1
+ {"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../semantic-release/base.js"],"names":[],"mappings":"AAAA,iDAAiD;AACjD,qBADW,OAAO,kBAAkB,EAAE,OAAO,CAgC3C"}
@@ -0,0 +1,4 @@
1
+ /** @type {import("semantic-release").Options} */
2
+ export const config: import("semantic-release").Options;
3
+ export default config;
4
+ //# sourceMappingURL=cross-publish.d.ts.map
@@ -0,0 +1 @@
1
+ {"version":3,"file":"cross-publish.d.ts","sourceRoot":"","sources":["../../semantic-release/cross-publish.js"],"names":[],"mappings":"AAEA,iDAAiD;AACjD,qBADW,OAAO,kBAAkB,EAAE,OAAO,CAiB3C"}
@@ -0,0 +1,58 @@
1
+ # [TypeScript](https://www.typescriptlang.org/) config
2
+
3
+ ## Installation
4
+
5
+ ```sh
6
+ npm install @peerigon/configs
7
+ ```
8
+
9
+ Then create a `tsconfig.json` just for type-checking next to your `package.json`:
10
+
11
+ ```json
12
+ {
13
+ "extends": "@peerigon/configs/typescript"
14
+ }
15
+ ```
16
+
17
+ Recommended configuration in your `package.json` (using [`npm-run-all`](https://www.npmjs.com/package/npm-run-all)):
18
+
19
+ ```json
20
+ {
21
+ "type": "module",
22
+ "scripts": {
23
+ "test": "run-p test:*",
24
+ "test:types": "tsc"
25
+ }
26
+ }
27
+ ```
28
+
29
+ In case you're developing a library with a dedicated build process, we recommend to create a separate `tsconfig.build.json`:
30
+
31
+ ```json
32
+ {
33
+ "extends": ["./tsconfig.json", "@peerigon/configs/typescript/lib"],
34
+ "include": ["src"],
35
+ "exclude": ["src/**/*.test.ts", "src/tests/**/*.ts"]
36
+ }
37
+ ```
38
+
39
+ with the following `package.json` `scripts`:
40
+
41
+ ```json
42
+ {
43
+ "type": "module",
44
+ "scripts": {
45
+ "build": "tsc -p tsconfig.build.json",
46
+ "test": "run-p test:*",
47
+ "test:types": "tsc"
48
+ }
49
+ }
50
+ ```
51
+
52
+ ## Presets
53
+
54
+ We export the following `tsconfig.json` presets. They can be used by extending `@peerigon/configs/<preset-name>`:
55
+
56
+ - `typescript`: Recommended base config for all modern TypeScript projects
57
+ - `typescript/lib`: Config for building TS libraries
58
+ - `typescript/js-lib`: Config for building JS libraries with [TS JSDoc annotations](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html).