Closed G-Rath closed 1 year ago
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":
dedent
's behavior has been the same for years now! I think we can consider this issue resolved by #36 and the issues you linked in two ways:
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.
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 🙂
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:
Thanks for raising!
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 theString.dedent
proposal because:String.dedent
if/when it landsAgain while
string-dedent
is a package that can be installed through npm, unless there is something people really disagree with in theString.dedent
proposal (which I think would be of serious concern anyway), I think there is value is having one of the most populardedent
libraries match its behaviour more.At the least the REPL indicates:
\\
to escape an escape (relates to #69)My personal concern is that
String.dedent
will come out with these subtle differences that mean I have to relearn how dedenting works - so havingdedent
start to mirrorString.dedent
more closely would address that.