Consider being String.dedent

[G-Rath]

I realise that string-dedent is apparently the polyfill (I don't know if its technically official, but it is the library used in the REPL), but I think there is value in mirroring the behaviour laid out in the String.dedent proposal because:

• it seems fairly stable
• it will enable users to more easily transition to using String.dedent if/when it lands
• it should help save on mental energy since behaviours have already been bikeshedded for the proposal

Again while string-dedent is a package that can be installed through npm, unless there is something people really disagree with in the String.dedent proposal (which I think would be of serious concern anyway), I think there is value is having one of the most popular dedent libraries match its behaviour more.

At the least the REPL indicates:

• escapes are always consumed - you have to do \\ to escape an escape (relates to Avoid escaping $ without a { after it? #69)
• only the first start and end newline are trimmed (Should only trim one newline at start and end so that you can add custom newlines #41)
• considers the first unintended line (Non-indented lines are ignored when calculating minimum indentation #20)
• gives the expected results for nested dedents (Add an option to recursively dedent nested template literal strings #12)

My personal concern is that String.dedent will come out with these subtle differences that mean I have to relearn how dedenting works - so having dedent start to mirror String.dedent more closely would address that.

[JoshuaKGoldberg]

My personal concern is that String.dedent will come out with these subtle differences that mean I have to relearn how dedenting works

Two issues on "will come out":

• Most of dedent's behavior has been the same for years now!
• The TC39 proposal is still only stage 2

I think we can consider this issue resolved by #36 and the issues you linked in two ways:

• All those issues will be resolved by adding an option, so folks can opt in or out of the behavior
• Per Project Status: Still Alive! #36 I'm trying not to significantly break existing (legacy) users.
  • Each of them will likely have to fix up some small breakages anyway if & when they migrate to the TC39 proposal after ratification

So, other than fixing all those issues with an option, I don't know that there's much to do until the proposal is ratified (stage 4). Then we can release a major version with all options set to the proposal's behavior. Thoughts?

Edit: Oh, and if someone wants to literally fill in String.dedent, I'd say they should just use the polyfill from the proposal. I wouldn't want to add that to this library. It'd be a pretty big jump in scope to cover behavior already present in the polyfill.

[G-Rath]

I think maybe I've muddy the water by using "polyfill" and not including the phrase "this should be done by options for now" in my original post 😅

I don't know how much more I can add that wouldn't just really be re-stating my original post either - I don't think the world will end if you decide to go a different path to what's been proposed to tc39 but at the same time I don't really feel like there's a lot of hate against the behaviours that would give reason to believe it's goings to change wildly..

Also I just didn't want to be an ass by way of posting the same "hey the tc39 proposal does this" comment on a bunch of issues and potentially derail them with a metadiscussion about the proposal 🙂

[JoshuaKGoldberg]

Closing out for now - if & when the TC39 dedent proposal hits stage 4, let's revisit. My suspicion is that this package would want to:

1. Add in any missing features from the TC39 proposal as opt-in options
2. Wait a little bit
3. Release a new major version where the default behavior matches the spec

Thanks for raising!