@0dep/toc 1.0.0 → 1.0.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.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,11 @@
2
2
 
3
3
  All notable changes to this project will be documented in this file.
4
4
 
5
+ ## v1.0.1 - 2026-09-12
6
+
7
+ - `updateToc` is removed and the library no longer imports anything from Node, so it runs in the browser too. Reading and writing files is the `toc` bin's job, use `buildToc` with your own IO
8
+ - the bin is ESM, `bin/toc.js`, and imports `index.js` directly
9
+
5
10
  ## v1.0.0 - 2026-09-12
6
11
 
7
12
  - provenance release
package/README.md CHANGED
@@ -17,7 +17,6 @@ The toc is written between `<!-- toc -->` and `<!-- /toc -->` markers, and only
17
17
  - [Options](#options-1)
18
18
  - [Output and exit code](#output-and-exit-code)
19
19
  - [Dry run](#dry-run)
20
- - [Keep the toc fresh with npm test](#keep-the-toc-fresh-with-npm-test)
21
20
  - [With prettier](#with-prettier)
22
21
  - [API](#api)
23
22
  - [`buildToc(source)`](#buildtocsource)
@@ -124,9 +123,9 @@ becomes
124
123
  Both take a summary text, `<!-- toc collapsible="Contents" -->` or `<!-- toc collapsed="Contents" -->`. Any other `name="value"` pair on the start marker is put on the summary element, in the order written:
125
124
 
126
125
  ```markdown
127
- <!-- toc collapsed="Contents" class="toc" style="font-weight: bold" -->
126
+ <!-- toc collapsed="Contents" title="Click to expand" style="font-weight: bold" -->
128
127
  <details>
129
- <summary class="toc" style="font-weight: bold">Contents</summary>
128
+ <summary title="Click to expand" style="font-weight: bold">Contents</summary>
130
129
 
131
130
  - [Install](#install)
132
131
 
@@ -134,7 +133,7 @@ Both take a summary text, `<!-- toc collapsible="Contents" -->` or `<!-- toc col
134
133
  <!-- /toc -->
135
134
  ```
136
135
 
137
- Renderers sanitise html, GitHub for one drops `style`, so check what yours keeps. The start marker itself is kept exactly as written, and spacing inside the comment does not matter.
136
+ Renderers sanitise html, so check what yours keeps. GitHub drops `style`, `class` and `id` but keeps `title`, `dir`, `lang`, `role` and `aria-*` attributes, so in the example above only the `title` survives there. The start marker itself is kept exactly as written, and spacing inside the comment does not matter.
138
137
 
139
138
  Anything on the start marker that is not one of the two options or a well-formed attribute makes the pair skip with a warning rather than guess: a bare name other than the two options, so a typo like `collapsable` is caught, an unquoted value like `collapsed=yes`, both options at once, or attributes without an option to give them a summary element.
140
139
 
@@ -202,25 +201,11 @@ npx toc --dry-run docs/new.md > toc.md
202
201
  docs/new.md: no TOC markers, skipped.
203
202
  ```
204
203
 
205
- ### Keep the toc fresh with npm test
206
-
207
- A typical setup regenerates the toc before the tests run and lints afterwards, this README is maintained that way:
208
-
209
- ```json
210
- {
211
- "scripts": {
212
- "pretest": "toc README.md",
213
- "test": "mocha",
214
- "posttest": "prettier . --check"
215
- }
216
- }
217
- ```
218
-
219
204
  ### With prettier
220
205
 
221
206
  The generated block is written the way prettier formats markdown, so the two do not fight: `-` bullets, two spaces per nesting level, a blank line before and after the list, and html on lines of its own. Running `prettier --write` over a generated toc changes nothing, and running `toc` over a prettier formatted toc changes nothing either. This README passes both.
222
207
 
223
- Run `toc` before `prettier --check`, as in the scripts above, so a stale toc is regenerated rather than reported as a formatting error. The order does not matter for the content: prettier leaves headings as written, setext underlines and closing hashes included, and it never breaks a line inside a link, so toc entries survive even `proseWrap: "always"`.
208
+ Run `toc` before `prettier --check` so a stale toc is regenerated rather than reported as a formatting error. The order does not matter for the content: prettier leaves headings as written, setext underlines and closing hashes included, and it never breaks a line inside a link, so toc entries survive even `proseWrap: "always"`.
224
209
 
225
210
  To regenerate the toc and format the rest of the file in one go, let a `posttoc` script run prettier with `--write` after `toc`. Prettier rewrites the prose and leaves the generated block as it is, so a second `toc` run reports the file up to date:
226
211
 
package/bin/toc.js CHANGED
File without changes
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@0dep/toc",
3
- "version": "1.0.0",
3
+ "version": "1.0.1",
4
4
  "description": "Generate a GitHub flavoured markdown table of contents",
5
5
  "type": "module",
6
6
  "sideEffects": false,
@@ -59,7 +59,7 @@
59
59
  "bugs": {
60
60
  "url": "https://github.com/zerodep/toc/issues"
61
61
  },
62
- "homepage": "https://0dep.se/tools",
62
+ "homepage": "https://0dep.se/toc/",
63
63
  "license": "MIT",
64
64
  "devDependencies": {
65
65
  "@eslint/js": "^10.0.1",