Eleventy: Expose `inputPath` in transforms
Linters support an inputPath argument but transforms do not
https://www.11ty.io/docs/config/#transforms
https://www.11ty.io/docs/config/#linters
Requested by @nhoizey https://twitter.com/nhoizey/status/1197932949708165120
zachleat
All 21 comments
This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open.
View the enhancement backlog here. Don’t forget to upvote the top comment with 👍!
zachleat
on 24 Nov 2019
If anyone needs this, until it is supported I use a little trick:
I put the inputPath in a data-attribute of the article element in the page's generated HTML:
data-input="{{ page.inputPath }}"
I then need to use jsdom (or regexes) to get the value inside the transform, but at least I get the value.
nhoizey
on 25 Nov 2019
Actually, I need both the inputPath and outputPath (even if the doc says "You probably won’t use this" 😅) in the transform's context.
I'm currently passing it from the template:
<body
…
data-img-src="{{ page.inputPath | dirname }}/"
data-img-dist="{{ page.outputPath | dirname }}/"
>
To the transform:
// Get images src and dist path from attributes on body
// TODO: move to context data
let documentBody = document.querySelector('body');
let srcPath = documentBody.getAttribute('data-img-src');
let distPath = documentBody.getAttribute('data-img-dist');
documentBody.removeAttribute('data-img-src');
documentBody.removeAttribute('data-img-dist');
https://www.npmjs.com/package/eleventy-plugin-local-respimg would benefit greatly from this as well
Snugug
on 14 Jan 2020
I'm still using the trick in https://github.com/11ty/eleventy/issues/789#issuecomment-564523509
My situation is the following:
I developed a plugin: eleventy-plugin-images-responsiver. It adds a transform.
_NB: Here, I'm not even sure I pass the plugin options as I should, it feels strange using a global variable for that: https://github.com/nhoizey/eleventy-plugin-images-responsiver/blob/master/.eleventy.js_
Anyway, this transform calls an imageResponsiver function that comes from another npm module: images-responsiver. This function doesn't need inputPath and outputPath.
But I need to be able to add inputPath and outputPath to the options (here imagesResponsiverOptions) before calling it, because this function calls other hook functions that I define in the plugin options, when adding it in my Eleventy config:
const imagesResponsiver = require('eleventy-plugin-images-responsiver');
const imagesResponsiverConfig = require('./src/_data/images-responsiver-config.js');
eleventyConfig.addPlugin(imagesResponsiver, imagesResponsiverConfig);
The imagesResponsiverConfig object comes from _data/images-responsiver-config.js.
It contains the runBefore and runAfter members, hook functions to run before and after the core of the imageResponsiver function.
In my current case, the runBefore function needs both inputPath and outputPath, and get them from the DOM of the transformed page:
let srcPath = documentBody.getAttribute('data-img-src');
let distPath = documentBody.getAttribute('data-img-dist').replace(/^dist/, '');
If inputPath was available as a parameter to the transform, I could add it to the imagesResponsiverOptions object for these hooks to get it.
_NB: I could already do it for outputPath, but I preferred having the same "passage way" for both variables._
Thanks for reading all of this, if you did… 😅
nhoizey
on 20 Mar 2020
Really sorry, this is getting punted to 1.0.
zachleat
on 10 May 2020
@zachleat no problem on my side, I have a work around which can last as long as you need.
nhoizey
on 10 May 2020
The awkward part of this is that the linter and transform arguments are going to be reversed. Hmm.
zachleat
on 16 May 2020
I think aligning them is a good idea. Given it'll be a breaking change for one of them, doing it either under 0.x or 1.x should be OK given that 0.x public APIs aren't considered stable under Semver (presuming you're keeping strict Semver)
On May 16, 2020, at 1:33 PM, Zach Leatherman notifications@github.com wrote:
The awkward part of this is that the linter and transform arguments are going to be reversed. Hmm.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Snugug
on 16 May 2020
I agree they should not be reversed for the future, and breaking it right know, before 1.0 (or for it) is better than later.
nhoizey
on 16 May 2020
imho best would be to have an object for options 🤔
eleventyConfig.addLinter("my-linter", (content, { inputPath, outputPath }) => {});
that way the order doesn't matter and additional info can get added without a breaking change.
PS: in my experience an options object generally better for optional infos
daKmoR
on 25 May 2020
any way we can help to make this happen? I mean the code change is "trivial" - so what info do we need to proceed?
we now patch it for our use case... but that is of course not a long term solution 😅
daKmoR
on 20 Jun 2020
It seems this one is needed in multiple places, breaking change(s) or not!!
TigersWay
on 26 Jul 2020
In a transform, can you not access the inputPath already, via this.inputPath? For example,
eleventyConfig.addTransform('myTransform', function(content, outputPath) {
console.log(this.inputPath)
})
(Not a long-term solution, I just wondered if this would work fine for now)
gregives
on 2 Aug 2020
Just to add a little something...
- First of all, thanks to @nhoizey for his neat trick,
- and then I had to go further, as I have - sometimes - multiple posts in one single page. It means one only
inputPathis not so interesting anymore, I went to add thatdata-pathto eacharticle.
TigersWay
on 4 Aug 2020
I actually need a different this in the function... but yeah it's now like that
const that = this;
this.elev.config.filters['hook-for-rocket'] = function hook(html, outputPath) {
const { inputPath } = this;
return that.doSomething(inputPath);
};
thx for the workaround 🤗
but yeah no workaround would be better 😬 so fixing this would still be nice 👍
daKmoR
on 5 Aug 2020
@TigersWay you should thank @gregives instead… 😅
nhoizey
on 11 Aug 2020
Code is in for this. We’re using this.inputPath and this.outputPath to avoid the argument order consistency problem with linters. We’ll keep support for the existing arguments but transition away from them in the docs.
More importantly, since it seems like y’all are using them here (specifically https://github.com/11ty/eleventy/issues/789#issuecomment-669298366): the object key filters is going away in 1.0 and will throw a contextual error message if you use it. It’s been deprecated since Eleventy 0.3.3 😅
Hopefully that workaround won’t be necessary anyway with this fix.
zachleat
on 30 Oct 2020
🚢🛳⛴🚀📦
zachleat
on 30 Oct 2020
Example of the error messaging:
zachleat
on 30 Oct 2020
That's awesome, thanks a lot Zach! 👍
nhoizey
on 30 Oct 2020
Related issues
michrome
·
3Comments
nilsmielke
·
4Comments
aaronstezycki
·
3Comments
jamrelian
·
3Comments
zac-heisey
·
3Comments
Most helpful comment
Code is in for this. We’re using
this.inputPathandthis.outputPathto avoid the argument order consistency problem with linters. We’ll keep support for the existing arguments but transition away from them in the docs.More importantly, since it seems like y’all are using them here (specifically https://github.com/11ty/eleventy/issues/789#issuecomment-669298366): the object key
filtersis going away in 1.0 and will throw a contextual error message if you use it. It’s been deprecated since Eleventy 0.3.3 😅Hopefully that workaround won’t be necessary anyway with this fix.