Add an option to recursively dedent nested template literal strings

[rattrayalex-stripe]

Hijacked by @JoshuaKGoldberg on September 4th, 2023: see https://github.com/dmnd/dedent/issues/12#issuecomment-1705819025. Now accepting PRs for a dedent({ recursive: true }) option.

---

const a = dedent`
hello
  world
`;
const b = dedent`
  foo.
  ${a}
  bar.
`;

results in

foo.
hello
world
bar.

instead of

foo.
hello
  world
bar.

This is unfortunate because it would be nice to compose dedented strings.

If you decide to fix this, any test cases should also check that inlined dedents make sense:

const weird = dedent`
  foo.
  ${things.map(x => dedent`
    hello
      world
  `).join('\n')}
  bar.
`;

[dralletje]

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.

[rattrayalex-stripe]

Awesome! Will discuss expected behavior in the PR

[ZhouHansen]

indentjs/endent endows suitable indentation for multiline interpolation.

[bertho-zero]

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

[ZhouHansen]

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

[bertho-zero]

This is not a neested endent.

[dralletje]

@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 :)

[ZhouHansen]

@dralletje that will be very helpful!

[d07RiV]

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

[dralletje]

@d07RiV Good find, updated it :)

[rattrayalex]

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!

[JoshuaKGoldberg]

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?

[bertho-zero]

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

[magicmark]

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`...`);

[JoshuaKGoldberg]

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 }).

[rattrayalex]

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!