saneef / eleventy-plugin-asciidoc Goto Github PK
View Code? Open in Web Editor NEWEleventy plugin to add support for AsciiDoc.
License: MIT License
Eleventy plugin to add support for AsciiDoc.
License: MIT License
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"?
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 */,
});
};
It would be really nice to support Mermaid and asciidoctor diagrams in asciidoc pages, like mermaid diagrams are supported in eleventy for markdown pages.
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')
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.
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>
----
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;
}
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.
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.
Original situation:
├── .eleventy.js
├── foo/
│ ├── bar/
│ │ └── baz.png
│ └── bar.adoc
└── _site/
└── foo/
└── bar/
├── baz.png
└── index.html
With Kroki, without imagesdir (broken):
├── .eleventy.js
├── foo/
│ ├── bar/
│ │ └── baz.png
│ ├── bar.adoc
│ └── diag-xxx.svg 👈 generated by Kroki
└── _site/
└── foo/
└── bar/
├── baz.png
└── index.html
With Kroki, with imagesdir=/img (broken):
├── .eleventy.js
├── foo/
│ ├── bar/
│ │ └── baz.png
│ └── bar.adoc
└── _site/
├── foo/
│ └── bar/
│ ├── baz.png
│ └── index.html 👈 references /img/baz.png
└── img/
└── diag-xxx.svg
With Kroki, imagesdir, and addPassthroughCopy workaround:
├── .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
With proposed solution:
├── .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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.