Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 Feature: Add an option to disable special character escaping #63

Closed
JoshuaKGoldberg opened this issue Jul 25, 2023 · 2 comments 路 Fixed by #65
Closed

馃殌 Feature: Add an option to disable special character escaping #63

JoshuaKGoldberg opened this issue Jul 25, 2023 · 2 comments 路 Fixed by #65
Assignees
Labels
type: feature New enhancement or request

Comments

@JoshuaKGoldberg
Copy link
Collaborator

This pulls together #2, #26, #45, #46:

I think the "right" (or: least unexpected) way would be to add an option with a not-very-savory name like escapeSpecialCharacters. The option would default to:

  • true when called for a template literal string
  • false when called as a function

Proposal:

  • Let's add this option in separately from fix: consume first level of escaping of $ and { characters聽#46, to resolve this issue and 26
  • I can release a new minor version that includes this option and 26
    • I'm a little hesitant to merge that PR before this option is in, in case folks are relying on the existing behavior

Thoughts @G-Rath @sirian?

@JoshuaKGoldberg JoshuaKGoldberg added type: feature New enhancement or request status: in discussion Not yet ready for implementation or a pull request labels Jul 25, 2023
@G-Rath
Copy link
Contributor

G-Rath commented Jul 25, 2023

Personally I would be considered about having different behaviour depending on how its called given you can do:

dedent(`my string`)

which cannot be detected as a template literal

@G-Rath
Copy link
Contributor

G-Rath commented Jul 25, 2023

Actually having thought about it a bit more, I think that default actually makes sense in reflection of the use-case:

  • being called as a function, it's most likely that the input is completely programmatic i.e. dedent(cmsData.text)
    • meaning you would want to have the content treated equal because any escaped template literal characters couldn't ever cause interpolation since its a computed string at that point
  • being called with template literals, it's most likely that the input is "decorative" i.e. ESLint test cases, reporter formatters, etc
    • meaning you would want to have template literal characters escaped, as they could cause interpolation hence why they were probably escaped

@JoshuaKGoldberg JoshuaKGoldberg removed the status: in discussion Not yet ready for implementation or a pull request label Jul 27, 2023
@JoshuaKGoldberg JoshuaKGoldberg self-assigned this Jul 27, 2023
JoshuaKGoldberg added a commit that referenced this issue Jul 30, 2023
Fixes #26. Fixes #63.

As described in #63, this introduces the concept of options with single
option, `escapeSpecialCharacters`. The option defaults to:

* `true` when called for a template literal's string tag
* `false` when called as a function

```js
// "\$hello!"
dedent.options({ escapeSpecialCharacters: false })`
  $hello!
`;
```

I'd played with allowing passing it in as a first argument instead of a
string or template literal strings array, but that got complex. I
suppose we can do that as a followup if people really want.

cc @G-Rath @sirian - what do you think?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature New enhancement or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants