Add an option to recursively dedent nested template literal strings about dedent HOT 16 OPEN

I needed exactly the same today, so #13 was born.
It now adds the indention of the line you interpolate on to every line in the interpolated string.

What would your preferred behaviour for the last example be?
In my code now, that would result (when you have 3 items in the things array) in this

foo.
hello
  world
hello
  world
hello
  world
bar.

from dedent.

@bertho-zero You are right. This is not because of the multiple indentation though. It is a bug in endent that makes it not work well with string that start without indentation at all.

This one (that clearly has one line indented and the other not indented) will output a totally not indented string
https://runkit.com/dral/5b036f8dabe4a00011e3e82e

Once you add a layer of indentation to all your lines, it gives the right output
https://runkit.com/dral/5b037090b225ba00122e66cf

@ZhouHansen This is a bug in endent - ofcourse you want to first apply endent to the substring.. not sure why you made your "right usage" so wrong ;)
I see you made me collaborator on that repo though, so I'll give fixing it a shot tomorrow :)

from dedent.

This is fixed with ts-dedent: https://runkit.com/embed/di4ek5toqg7o

from dedent.

Awesome! Will discuss expected behavior in the PR

from dedent.

indentjs/endent endows suitable indentation for multiline interpolation.

from dedent.

@ZhouHansen This issue exist also with endent: https://runkit.com/embed/fx2ssy6zqm9x

from dedent.

@bertho-zero , here's the right usage: https://runkit.com/zhouhansen/5b023b1fd78bc100121e15f8

from dedent.

This is not a neested endent.

from dedent.

@dralletje that will be very helpful!

from dedent.

@dralletje you didn't compile your fork, so it still has the same dist code.

from dedent.

@d07RiV Good find, updated it :)

from dedent.

Thank you @ZhouHansen , I confirm that the endent package has the behavior I want – I have replaced all uses of dedent with it.

By the way, it looks like endent now has over 2.5mm downloads/wk, congrats!

from dedent.

Hmm, I can see why you'd want this behavior... but also it's a bit counter-intuitive to how the package is positioned right now IMO. Today, it's used as a "dedent everything in this string" utility - not a "dedent this string, and still allow indents in some contents".

Perhaps this can become an opt-in? A couple of API starting ideas..

dedent.recursive`
  ${text}
`;

dedent({ recursive: true })`
  ${text}
`;

Thoughts, everyone?

from dedent.

Perhaps this can become an opt-in? A couple of API starting ideas..
...
Thoughts, everyone?

@JoshuaKGoldberg thanks for pointing me here! To provide some feedback on this - I use this package a lot (I write a lot of cli tooling in particular that spits out formatted error messages to users) and 10/10 times this is the default behavior i'm looking for. That said, I understand and totally respect it's a question of scope and not wanting to fundamentally change (in a backwards incompatible way) the behaviour of this significantly depended-on library!

With that in mind, I feel like it's worthy enough of being a top level namespace thing (rather than buried as an option), and so I like what you initially suggested the most:

dedent.recursive`...`

fwiw in terms of API ideas, here's some prior art for a similar thing in execa: https://github.com/sindresorhus/execa#shared-options - so you'd suggest something like:

import dedent from 'dedent';
const ddedent = dedent({ recursive: true });
console.log(ddedent`...`)

I don't personally love this, the $$ example is neat enough but ddedent or anything else i can think of just looks weird and non obvious. but maybe if you could come up with a catchy alias it could be nice.

3rd option (which could go alongside as an alias of the first option)

import { recursive as dedent } from 'dedent';
console.log(dedent`...`);

from dedent.

The dedent.recursive option is definitely appealing. A similar idea came up with escapeSpecialCharacters too, like dedent.escapeSpecialCharacters. The one issue is that we'd then have to content with a whole bunch of potential options there. Would dedent.escapeSpecialCharacters.recursive need to work too?

For now, let's add it in as an opt-in option: dedent({ recursive: true }).

from dedent.

Thoughts, everyone?

Heh, hey @JoshuaKGoldberg ! Good to see you here! Sorry I missed this before.

FWIW, it's not my expected behavior to have the library dedent most things, except child strings. I consider the current behavior a bug, not a separate feature, though I may be missing something.

I wouldn't want to have to use an option for a library like this – more specifically, I wouldn't want to have to police that everyone in my codebase always calls the recursive version.

I could maybe be okay with import dedent from 'dedent/recursive', but really I'd much rather this just be the default behavior (though I'll admit it may require a major version bump).

For now, personally, I'd probably simply stick with ts-dedent which has this behavior out of the box (as well as TS types) if a recursive option were added.

Just my 2c!

from dedent.