dmnd/dedent

Consider being `String.dedent`

Closed this issue · 3 comments

G-Rath commented

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 #69)
  • only the first start and end newline are trimmed (#41)
  • considers the first unintended line (#20)
  • gives the expected results for nested dedents (#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 commented

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 #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 commented

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 🙂

  • 😄1
JoshuaKGoldberg commented

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!