You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: apps/site/pages/en/learn/modules/publishing-a-package.mdx
+13-7Lines changed: 13 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ authors: JakobJingleheimer
6
6
7
7
# Publishing a package
8
8
9
-
All the provided `package.json` configurations (not specifically marked “does not work”) work in Node.js 12.22.x (v12 latest, the oldest supported line) and 17.2.0 (current latest at the time)[^1], and for grins, with webpack 5.53.0 and 5.63.0 respectively. These are available: [JakobJingleheimer/nodejs-module-config-examples](https://github.com/JakobJingleheimer/nodejs-module-config-examples).
9
+
All the provided `package.json` configurations (not specifically marked “does not work”) work in Node.js 12.22.x (v12 latest, the oldest supported line) and 17.2.0 (current latest at the time)\[^1], and for grins, with webpack 5.53.0 and 5.63.0 respectively. These are available: [JakobJingleheimer/nodejs-module-config-examples](https://github.com/JakobJingleheimer/nodejs-module-config-examples).
10
10
11
11
For curious cats, [How did we get here](#how-did-we-get-here) and [Down the rabbit-hole](#down-the-rabbit-hole) provide background and deeper explanations.
12
12
@@ -36,19 +36,23 @@ There are other options available, mostly for historical purposes.
36
36
<td>ESM: consumers <code>import</code> your package</td>
37
37
<td><ahref="#cjs-source-and-only-esm-distribution">CJS source and only ESM distribution</a></td>
38
38
</tr>
39
+
39
40
<tr>
40
41
<td>CJS & ESM: consumers either <code>require()</code> or <code>import</code> your package</td>
41
42
<td><ahref="#cjs-source-and-both-cjs-amp-esm-distribution">CJS source and both CJS & ESM distribution</a></td>
42
43
</tr>
44
+
43
45
<tr>
44
46
<tdrowSpan="2">ESM source code using <code>import</code></td>
45
47
<td>CJS: consumers <code>require()</code> your package (and you use top-level <code>await</code>)</td>
46
48
<td><ahref="#esm-source-with-only-cjs-distribution">ESM source with only CJS distribution</a></td>
47
49
</tr>
50
+
48
51
<tr>
49
52
<td>CJS & ESM: consumers either <code>require()</code> or <code>import</code> your package</td>
50
53
<td><ahref="#esm-source-and-both-cjs-amp-esm-distribution">ESM source and both CJS & ESM distribution</a></td>
51
54
</tr>
55
+
52
56
</tbody>
53
57
</table>
54
58
@@ -333,7 +337,7 @@ We're not in Kansas anymore, Toto.
333
337
334
338
The configurations (there are 2 options) are nearly the same as [ESM source and both CJS & ESM distribution](#esm-source-and-both-cjs-amp-esm-distribution), just exclude `packageJson.exports.import`.
335
339
336
-
💡 Using `"type": "module"`[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
340
+
💡 Using `"type": "module"`\[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
@@ -382,7 +386,7 @@ If your files explicitly _all_ use `.cjs` and/or `.mjs` file extensions (none us
382
386
}
383
387
```
384
388
385
-
💡 Using `"type": "module"`[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
389
+
💡 Using `"type": "module"`\[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
386
390
387
391
#### Publish a CJS distribution with an ESM wrapper
388
392
@@ -422,7 +426,7 @@ This is also almost identical to the [CJS source and dual distribution using an
422
426
}
423
427
```
424
428
425
-
💡 Using `"type": "module"`[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
429
+
💡 Using `"type": "module"`\[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
426
430
427
431
#### Publish both full CJS & ESM distributions
428
432
@@ -494,7 +498,7 @@ Alternatively, you can use `"default"` and `"node"` keys, which are less counter
494
498
}
495
499
```
496
500
497
-
💡 Using `"type": "module"`[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
501
+
💡 Using `"type": "module"`\[^2] paired with the `.cjs` file extension (for commonjs files) yields best results. For more information on why, see [Down the rabbit-hole](#down-the-rabbit-hole) and [Gotchas](#gotchas) below.
498
502
499
503
##### Use the `.mjs` (or equivalent) file extension for all source code files
500
504
@@ -523,9 +527,11 @@ The `"engines"` field provides both a human-friendly and a machine-friendly indi
523
527
Specifically in relation to Node.js, there are 4 problems to solve:
524
528
525
529
- Determining format of source code files (author running their own code)
530
+
526
531
- Determining format of distribution files (code consumers will receive)
527
532
528
533
- Publicising distribution code for when it is `require()`’d (consumer expects CJS)
534
+
529
535
- Publicising distribution code for when it is `import`’d (consumer probably wants ESM)
This does not work because `packageJson.exports["."].import` will get interpreted as CJS (but it’s actually ESM).
594
600
595
-
[^1]: There was a bug in Node.js v13.0–13.6 where `packageJson.exports["."]` had to be an array with verbose config options as the first item (as an object) and the “default” as the second item (as a string). See [nodejs/modules#446](https://github.com/nodejs/modules/issues/446).
601
+
\[^1]: There was a bug in Node.js v13.0–13.6 where `packageJson.exports["."]` had to be an array with verbose config options as the first item (as an object) and the “default” as the second item (as a string). See [nodejs/modules#446](https://github.com/nodejs/modules/issues/446).
596
602
597
-
[^2]: The `"type"` field in package.json changes what the `.js` file extension means, similar to to an [HTML script element’s type attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#attr-type).
603
+
\[^2]: The `"type"` field in package.json changes what the `.js` file extension means, similar to to an [HTML script element’s type attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#attr-type).
Copy file name to clipboardExpand all lines: apps/site/pages/fr/about/security-reporting.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,4 +85,4 @@ Si vous avez des suggestions sur la façon dont ce processus pourrait être amé
85
85
/>
86
86
</a>
87
87
88
-
Le [badge des meilleures pratiques] de l'Open Source Security Foundation (OpenSSF) (https://github.com/coreinfrastructure/best-practices-badge) est un moyen pour les projets de logiciels libres et open source (FLOSS) de montrer qu'ils suivent les meilleures pratiques. Les projets peuvent volontairement auto-certifier la manière dont ils suivent chaque meilleure pratique. Les utilisateurs du badge peuvent rapidement déterminer quels sont les projets FLOSS qui suivent les meilleures pratiques et qui sont donc plus susceptibles de produire des logiciels sécurisés de meilleure qualité.
88
+
Le \[badge des meilleures pratiques] de l'Open Source Security Foundation (OpenSSF) (https://github.com/coreinfrastructure/best-practices-badge) est un moyen pour les projets de logiciels libres et open source (FLOSS) de montrer qu'ils suivent les meilleures pratiques. Les projets peuvent volontairement auto-certifier la manière dont ils suivent chaque meilleure pratique. Les utilisateurs du badge peuvent rapidement déterminer quels sont les projets FLOSS qui suivent les meilleures pratiques et qui sont donc plus susceptibles de produire des logiciels sécurisés de meilleure qualité.
A [`remark-lint`](https://github.com/remarkjs/remark-lint) plugin with configurations tailored to the documentation and contribution standards of the [Node.js GitHub Organization](https://github.com/nodejs).
4
+
5
+
## Installation
6
+
7
+
```bash
8
+
npm install --save-dev @node-core/remark-lint
9
+
```
10
+
11
+
## Usage
12
+
13
+
Add the plugin to your `.remarkrc` or `remark.config.js`:
14
+
15
+
```json
16
+
{
17
+
"plugins": ["@node-core/remark-lint"]
18
+
}
19
+
```
20
+
21
+
You can then run `remark` over your markdown files:
22
+
23
+
```bash
24
+
npx remark . --frail
25
+
```
26
+
27
+
## Settings
28
+
29
+
### `NODE_RELEASED_VERSIONS`
30
+
31
+
Some lint rules (such as `node-core:yaml-comments`) require knowledge of released Node.js versions to validate version references.
32
+
33
+
You can provide these using the `NODE_RELEASED_VERSIONS` environment variable:
0 commit comments