Latest version of asciidoctor.js is 3.0.2.
It would be great to have the latest version in this plugin.

A switch from asciidoctor to @asciidoctor/core can be a good idea as "asciidoctor" is juste an export from "'@asciidoctor/core'" module.exports = require('@asciidoctor/core')

Using eleventy 1.0.1 and this plugin 1.3.1.

Adding permalink in the front matter:

<!-- hello.adoc -->
---
permalink: /hello-permalink
---

= Hello Title

Hello content

Running eleventy:

❯ yarn run eleventy
yarn run v1.22.18
warning ../../package.json: No license field
$ /Users/i/Works/mstest/node_modules/.bin/eleventy
[11ty] Writing _site/<div class="paragraph">
[11ty] <p>Hello content</p>
[11ty] </div> from ./hello.adoc

which seems the rendered content is being used as permalink. I dug into eleventy source code a little, but have yet to find the crux of this.

I followed the instructions in the README, however the title doesn't come across on the generated HTML page.

= Title goes here
lorem ispum dolor sit amet, consectetur adipiscing elit. 
Donec eget enim eu lectus tempor rhoncus. Nulla facilisi.

== Section 1
lore ispum dolor sit amet, consectetur adipiscing elit. 
Donec eget enim eu lectus tempor rhoncus. Nulla facilisi.

=== Section 1a
lorem ispum dolor sit amet, consectetur adipiscing elit. 
Donec eget enim eu lectus tempor rhoncus. Nulla facilisi.

=== Section 1b
lorem ispum dolor sit amet, consectetur adipiscing elit. 
Donec eget enim eu lectus tempor rhoncus. Nulla facilisi.

== Section 2
lorem ispum dolor sit amet, consectetur adipiscing elit. 
Donec eget enim eu lectus tempor rhoncus. Nulla facilisi.

CONFIG:

const eleventyAsciidoc = require("eleventy-plugin-asciidoc");

module.exports = function (eleventyConfig) {
  eleventyConfig.addPlugin(eleventyAsciidoc, {
    showtitle: true /* Default value: true */,
    safe: "unsafe" /* Default value: undefined */,
  });
};

The output I get is :

With version 2.0.0 of the plugin, it was possible to register asciidoctor extensions using code like:

const eleventyAsciidoc = require("eleventy-plugin-asciidoc");

const asciidoctor = require("asciidoctor").default();
const registry = asciidoctor.Extensions.create();
require("./my-extension.js")(registry);

module.exports = function (eleventyConfig) {
  eleventyConfig.addPlugin(eleventyAsciidoc, {
    extension_registry: registry,
  });
};

This no longer works with version 3.

I suppose it comes from upstream Asciidoctor.js changes that now requires the registry to have been created from the same asciidoctor instance; anyway, we cannot update to version 3 due to that change, and I'd suggest providing a proper and future-proof way to register asciidoctor extensions in the plugin: a callback function passed in the options that the plugin would call (if present) with an extension registry (or with the asciidoctor.Extensions object directly).

From the user point of view, it would be used as:

const eleventyAsciidoc = require("eleventy-plugin-asciidoc");

module.exports = function (eleventyConfig) {
  eleventyConfig.addPlugin(eleventyAsciidoc, {
    register_extensions(registry) {
      require("./my-extension.js")(registry);
    },
  });
};

And from inside the plugin, it could be along the lines of:

const { register_extensions, ...options } = eleventyOptions;

if (register_extensions) {
  const registry = processor.Extensions.create();
  register_extensions(registry);
  options.extension_registry = registry;
}

I expected that an included file was relative to the current document.

----
include::an-included-file.txt[]
----

but the :docdir: attribute is set to the root of the project, perhaps an option to changed it for each document can be added.

Context:

We've been using this plugin to process our pages and initially didn't configure an imagesdir.
That way, a page at foo/bar.adoc will output to _site/foo/bar/index.html, and image: macros would generate relative URLs so image:baz.png[] in that page would generate an <img src=baz.png, and we organized our images as foo/bar/baz.png with a addPassthroughCopy("**/*") (not the actual glob, setup is more complex than that) to copy them to _site/foo/bar/baz.html.

We've then added asciidoctor-kroki to be able to put diagrams in our asciidoc. This extension however will either generate images next to the source file (due to how base_dir is set) or require setting an imagesdir. This means that either diagrams are generated at the wrong place and don't display, or our previous images no longer display as they're now generated as <img src=/img/baz.png (assuming imagesdir: "/img")

Workaround:

The workaround to this is to rewrite our addPassthroughCopy to copy our images to that same imagesdir, but this creates another problem: we can no longer have 2 image files with the same name! (also, because we have more than just images, we need two addPassthroughCopy: one to match the non-image files, with the same behavior as previously, and one to match the image files to put them to the imagesdir.

Proposed solution:

I'd like to propose that a mechanism be added to this plugin to allow computing attributes to be set dynamically for each page (just like the base_dir nowadays). This should (that's my expectation at least) allow us to configure asciidoctor-kroki's outdir to the output directory of the page; that way, we could revert to our previous configuration for our images, and have asciidoctor-kroki output to that exact same directory as well, e.g. _site/foo/bar/diag-xxxx.svg.

This might not work (depending on how Eleventy calls the plugin) so I'm obviously open to other ideas.

├── .eleventy.js
├── foo/
│   ├── bar/
│   │   └── baz.png
│   └── bar.adoc
└── _site/
    └── foo/
        └── bar/
            ├── baz.png
            └── index.html

├── .eleventy.js
├── foo/
│   ├── bar/
│   │   └── baz.png
│   ├── bar.adoc
│   └── diag-xxx.svg  👈  generated by Kroki
└── _site/
    └── foo/
        └── bar/
            ├── baz.png
            └── index.html

├── .eleventy.js
├── foo/
│   ├── bar/
│   │   └── baz.png
│   └── bar.adoc
└── _site/
    ├── foo/
    │   └── bar/
    │       ├── baz.png
    │       └── index.html  👈  references /img/baz.png
    └── img/
        └── diag-xxx.svg

├── .eleventy.js
├── foo/
│   ├── bar/
│   │   └── baz.png
│   └── bar.adoc
└── _site/
    ├── foo/
    │   └── bar/
    │       └── index.html
    └── img/
        ├── baz.png  👈  could conflict with another baz.png for another page
        └── diag-xxx.svg

├── .eleventy.js
├── foo/
│   ├── bar/
│   │   └── baz.png
│   └── bar.adoc
└── _site/
    └── foo/
        └── bar/
            ├── baz.png  👈  can be referenced with <img src=baz.png> as initially
            ├── diag-xxx.svg
            └── index.html

It would be really nice to support Mermaid and asciidoctor diagrams in asciidoc pages, like mermaid diagrams are supported in eleventy for markdown pages.

It's me again lol

As of 11ty 1.0.1, asciidocAttributes is written directly onto data, thus accessible through asciidocAttributes in templates, and no more page.asciidocAttributes.

Btw, since it's a rather "breaking" change, how about changing it to a shorter name, like "adocAttrs"?

When including source code examples I rely on a custom path attribute like:

[source,java]
----
include::{examplesdir}/spring/restclienttest/src/main/java/de/eiswind/restclienttest/SomeWildApiClient.java[tag=snip]
----
<1> some callout text

this works fine, but i get warnings in getData about callouts not being found, and my guess would be that the examplesdir attribute is not defined when processer.load gets called.

I could try to create a PR if you agree and pass available ProcessorOptions to load.

Would it be possible to add syntax highlighting support for source code blocks?

So that, for example, the following AsciiDoc source would be nicely highlighted in the output:

[source,html]
----
<body>
  <p>This is some HTML</p>
</body>
----

When using Markdown, Markdown files are preprocessed (by default by Liquid).

This allows access to the data transmitted by Eleventy in the Markdown page.

It would be great to have this feature with AsciiDoc.

That said, I don't know if it's easy to retrieve the template engines configured in Eleventy.