Is there a plan to integrate this update into hugo? Or shall we go with manual update still?

Is there a plan to integrate the last minify release with this feature into hugo? Or shall we stil manually update?

One can hugo --path-warnings to print warnings on duplicate target paths. I'd like to stop the build (error instead of warning) when this happens. Something like hugo --path-errors ...

Yes, I can grep the output, but it would be easier if it were built-in.

Please close this issue if it has no chance of happening.

Cool. I'm in the same mood as you.

would the preference be: to write articles (tutorials/how-tos etc to add to existing docs) fresh? Or link to existing ones?

I personally prefer to start fresh, to help consistency and coherence, even if it will be more work. And we can also have a sort of footnote/info box with a link to the original article + citation.

Will look at the spreadsheet. And I agree that we only should start if this way of seing doc evolution is in phase with what bep's and al. are ok with. It is out of question to force/go against the way they think is good for the doc.

Re forum vs issue, I think forum in this situation leads to unefficient bla bla frompeople who do not want to really be involved. So may be start and define the rough aspects here and then later, discuss the details on the forum ??

I suppose a good place to start is the question of direction, which overlaps with 1. 2. and 4. above.

Do we take the 4-part documentation suggestion (ie tutorials, how-to, explanation, reference) as the goal?

If no: what instead?

If yes: would the preference be: to write articles (tutorials/how-tos etc to add to existing docs) fresh? Or link to existing ones?

Related to 4., and with the assumption of the 4-part segmentation as the goal, I've started a spreadsheet.

I copied the existing documentation sections + pages and noted where these might fall under the four main divisions. It needs more work of course, but I thought I'd get the discussion started.

I'm happy to continue to work on this unless I am wildly off-mark with what the rest of the contributors/community/gang thinks. Which would then bring us back to the question of direction.

Also: Would it be better to discuss this in the forums? We might have more eyeballs there, which is both good and bad.

If all three (element id, CSS classes, and additional attributes) were possible, I would vote to control them separately. Something like:

[markup.goldmark.extensions]
  attributes = true
  [markup.goldmark.extensions.attributes]
     elementIDs = false
     cssClasses = true
     additionalAttributes = false

The additionalAttributes should be limited an "allow list". And at some point someone will ask for an "allow list" for cssClasses as well.

I agree with @bep 's opinion. Reasons why I wont to add general attributes to the goldmark core:

1. It can be implemented (mostly) as an extension.

   • It is hard to implement heading attributes as an extension, so I've implemented it in the core.

2. There are many interpretations for attributes positions and I do not know which is the best.

   1. Attribute is in one line above an element:

      {.class}
      > foo
      > bar
      

   2. Attribute is in one line below an element:

      > foo
      > bar
      {.class}
      

      1. Special case: blockquote can be:

      > foo
      > bar
      > {.class}
      

      2. (There may be other special cases)

3. Some elements do not have suitable syntax for attributes:

   1. Lists
   2. Table cells

If this is added at some point, I hope it is disabled by default. Not because I don't like the idea (I do), but because separation of content and style seems like the right starting point for most projects.

[markup.goldmark.extensions]
      attributes = false

PS: yes I used the wrong word, tag, and created confusion sorry. :see_no_evil:

The cite element is not a style. It's a sub-element to demark the source of a blockquote. You closed this without reading the issue on top. There is no way to write a cite element with proper markdown and without adding HTML to the markdown.

• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/cite
• https://stackoverflow.com/questions/2002120/citing-the-author-of-a-blockquote-using-markdown-syntax

Although I had not thought of blockquotes, this reminds me of my wondering about render hooks for all sorts of tags. https://discourse.gohugo.io/t/markdown-render-hooks-for-all-the-things/28782

Bumps github.com/evanw/esbuild from 0.8.15 to 0.8.16. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/releases">github.com/evanw/esbuild's releases</a>.</em></p> <blockquote> <h2>v0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/blob/master/CHANGELOG.md">github.com/evanw/esbuild's changelog</a>.</em></p> <blockquote> <h2>0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/evanw/esbuild/commit/f4cec94deaa61e5bb9bd3c0d14ad37ead1d8ca55"><code>f4cec94</code></a> publish 0.8.16 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/7ba75db79fc0d328a3b4dc039c04b7ff142d31ef"><code>7ba75db</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a></li> <li><a href="https://github.com/evanw/esbuild/commit/f8eb7595e4b16f7e235941b39eac59234af92396"><code>f8eb759</code></a> make <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a> backward-compatible</li> <li><a href="https://github.com/evanw/esbuild/commit/0e356b1852aad23d25726b7ce5a9a0242bcb41c4"><code>0e356b1</code></a> support custom host in serve api (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/8e9a4d5310c82cb1628af0eb0e903eb5a86f88ac"><code>8e9a4d5</code></a> release notes for "process.env.NODE_ENV" change</li> <li><a href="https://github.com/evanw/esbuild/commit/34c5305c174cb95dd2c01fe6f86ee90cfa6d33fc"><code>34c5305</code></a> warn about "process.env.NODE_ENV" with identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/4e503ba2ada87da775d918d77e6ce035a51dce37"><code>4e503ba</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>: avoid a warning for "require.main"</li> <li><a href="https://github.com/evanw/esbuild/commit/3b049b2083a624fb287c96bef23c9fb8d41d3e9f"><code>3b049b2</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a></li> <li><a href="https://github.com/evanw/esbuild/commit/fe795c93f11811f3ab5020078a578d422021b2cc"><code>fe795c9</code></a> types: overload <code>build</code> definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/561">#561</a>)</li> <li>See full diff in <a href="https://github.com/evanw/esbuild/compare/v0.8.15...v0.8.16">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

Superseded by #8004.

Bumps github.com/evanw/esbuild from 0.8.15 to 0.8.17. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/releases">github.com/evanw/esbuild's releases</a>.</em></p> <blockquote> <h2>v0.8.17</h2> <ul> <li> <p>Get esbuild working on the Apple M1 chip via Rosetta 2 (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/564">#564</a>)</p> <p>The Go compiler toolchain does not yet support the new Apple M1 chip. Go version 1.15 is currently in a feature freeze period so support will be added in the next version, Go 1.16, which will be <a href="https://blog.golang.org/11years#TOC_3.">released in February</a>.</p> <p>This release changes the install script to install the executable for macOS <code>x64</code> on macOS <code>arm64</code> too. Doing this should still work because of the executable translation layer built into macOS. This change was contributed by <a href="https://github.com/sod">@sod</a>.</p> </li> </ul> <h2>v0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/blob/master/CHANGELOG.md">github.com/evanw/esbuild's changelog</a>.</em></p> <blockquote> <h2>0.8.17</h2> <ul> <li> <p>Get esbuild working on the Apple M1 chip via Rosetta 2 (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/564">#564</a>)</p> <p>The Go compiler toolchain does not yet support the new Apple M1 chip. Go version 1.15 is currently in a feature freeze period so support will be added in the next version, Go 1.16, which will be <a href="https://blog.golang.org/11years#TOC_3.">released in February</a>.</p> <p>This release changes the install script to install the executable for macOS <code>x64</code> on macOS <code>arm64</code> too. Doing this should still work because of the executable translation layer built into macOS. This change was contributed by <a href="https://github.com/sod">@sod</a>.</p> </li> </ul> <h2>0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/evanw/esbuild/commit/8a2b1082da1b0f5fbfd8ca9f88eccee88a22007a"><code>8a2b108</code></a> publish 0.8.17 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/918d44e7e2912fa23f9ba409e1d6623275f7b83f"><code>918d44e</code></a> relocate "var" to the top level when bundling</li> <li><a href="https://github.com/evanw/esbuild/commit/91756250c72fbed65db1c09a414493fea5b378cc"><code>9175625</code></a> no need to sort reachable files</li> <li><a href="https://github.com/evanw/esbuild/commit/d926cebcc3fffce6e12aa345ae741211353fe6e2"><code>d926ceb</code></a> remove warnings with gopls</li> <li><a href="https://github.com/evanw/esbuild/commit/9c473496a0b5e7bf7f81e183b1ba25807d1b9133"><code>9c47349</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/564">#564</a> (see also <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/550">#550</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/c43d4a8e2c0fd33cf6fee83d9e70401a4bb18346"><code>c43d4a8</code></a> fix: allow and pick darwin x86_64 binary on apple silicon macs (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/564">#564</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/f4cec94deaa61e5bb9bd3c0d14ad37ead1d8ca55"><code>f4cec94</code></a> publish 0.8.16 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/7ba75db79fc0d328a3b4dc039c04b7ff142d31ef"><code>7ba75db</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a></li> <li><a href="https://github.com/evanw/esbuild/commit/f8eb7595e4b16f7e235941b39eac59234af92396"><code>f8eb759</code></a> make <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a> backward-compatible</li> <li><a href="https://github.com/evanw/esbuild/commit/0e356b1852aad23d25726b7ce5a9a0242bcb41c4"><code>0e356b1</code></a> support custom host in serve api (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a>)</li> <li>Additional commits viewable in <a href="https://github.com/evanw/esbuild/compare/v0.8.15...v0.8.17">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

I came across this when convert my Jekyll-style site to Hugo, I would like my posts organzied like :year-:month:-:day-:slug.md, and have url as {root}/:year/:month/:day/:slug/, maybe we can just extend permalinks to add a new keyword: :jekyll, and config looks like this

[permalinks]
  posts = "/:jekyll/"

related discussion: https://discourse.gohugo.io/t/extracting-date-and-slug-from-filename/8394/8

Replicate this issue consistently with markdownify.

When feeding the following with markdownify $html | safeHTML:

### My Card Title Here
This can be written in Markdown where it will be processed into HTML
automatically.

I got a missing </p> with its generated HTML output:

<h3 id="my-card-title-here">My Card Title Here</h3>
<p>This can be written in Markdown where it will be processed into HTML
automatically.

I'm on:

Hugo Static Site Generator v0.78.2-959724F0 linux/amd64 BuildDate: 2020-11-13T10:08:14Z

Just some additional thought, can we set also pnpm or yarn instead of npm or would we have to create our own wrapper for this? Just asking because I'm not a big friend of npm and generally use yarn or pnpm which is much better (less disk usage).

This is proposed additional English-language documentation for how to host a Hugo site on Cloudflare Workers with KV storage.

Ah, I found it =)

https://github.com/gohugoio/hugo/blob/e442cf30a215e33b49ce588a9098147282bd883f/hugolib/site.go#L514

No; if you provide a related configuration, it must be complete.

Yes, I already understood this =) And I thought the example in the docs was complete. Still, I can not see in the sourcecode where it falls back to tags. Can you point me to it? Thanks =)

At least there are many parts that use tags instead of keywords.

https://github.com/gohugoio/hugo/search?q=tags&type=

I only see https://github.com/gohugoio/hugo/blob/f37e77f2d338cf876cfa637a662acd76f0f2009b/related/inverted_index.go#L54-L56 but where is the logic that falls back to tags instead of keywords for related content? Would be helpful if you can point me to it =)

FYI, what I finally did, as I had the case for both partials and shortcodes, is setting a boolean to true in the partial/shortcode using .Scratch.Set, and checking for that boolean to include or not my javascripts. These are all in the footer, after the shortcodes. I have not tested if this work for CSS in the <head> though.

Because I can not change a related setting without having to change it to tags.

I think this part is missing in the linked section and should be at least documented / mentioned.

If you provide a config section, that is the config section we use, I don't see how we can magically determine "oh, he probably meant tags, not keywords"...?

Correct. But according to the docs the default config is like described in the docs. But as you state and I can see this is not the whole truth (tags fallback).

If you don't provide any related config, we use the default. Reading the code, I see we also check for the presence of a tags config, so in case no config would have worked for you.

Correct. But what has the cobfig to look like to reproduce this behavior, which is not described in the docs?