New 'negative lookbehind' regex breaks in IOS & Safari versions < 16.4

[lllleonnnn]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

2.0.1

Link to runnable example

No response

Steps to reproduce

Run latest 2.0.1 on any Safari version below 16.4

Expected behavior

Expected behavior is that no errors should be thrown

Actual behavior

When using this as part of rendering markdown in React apps, will throw SyntaxError: Invalid regular expression: invalid group specifier name and crash application.

Affected runtime and version

'browser'@2.0.1

Affected package manager and version

No response

Affected OS and version

iOS <= 16.3

Build and bundle tools

No response

[ChristianMurphy]

Welcome @nowfred! 👋
This project targets ES2022, older versions of the spec are not part of the support matrix.

Safari 16.4 and below do not support ES2022 out of the box.
You can transpile/polyfill this with babel, take a look at https://github.com/slevithan/babel-plugin-transform-regex

Related to remarkjs/react-markdown#800 and remarkjs/react-markdown#822

[lllleonnnn]

Thank you @ChristianMurphy no worries - I personally appreciate finding issues like this when I'm debugging so wanted to leave for posterity. Appreciate your prompt reply and explanation.

[vktrl]

Welcome @nowfred! 👋 This project targets ES2022, older versions of the spec are not part of the support matrix.

Safari 16.4 and below do not support ES2022 out of the box. You can transpile/polyfill this with babel, take a look at https://github.com/slevithan/babel-plugin-transform-regex

Related to remarkjs/react-markdown#800 and remarkjs/react-markdown#822

@ChristianMurphy, please reconsider using a backwards-compatible regex or an option to specify one.

It can't be polyfilled and the babel transformer does not fix it.

Check the REPL and see that the pattern that's causing the problem is not being transformed: /(?<=^|\s|\p{P}|\p{S})([-.\w+]+)@([-\w]+(?:\.[-\w]+)+)/gu

For anyone else having this problem, I'm using pnpm to force compatible version for now:

// .pnpmfile.cjs

function readPackage(pkg, context) {
  if (pkg.name === 'mdast-util-gfm') {
    pkg.dependencies = {
      ...pkg.dependencies,
      'mdast-util-gfm-autolink-literal': '2.0.0',
    };
    context.log('mdast-util-gfm -> [email protected]');
  }

  return pkg;
}

module.exports = {
  hooks: {
    readPackage,
  },
};

[wooorm]

Sad that that polyfill doesn’t seem to do lookbehinds.

“Backwards compatible” to what? The stone age? I don’t think it is reasonable to be compatible with ancient things.

There is of course some decent compatibility, which is outlined in the readme: https://github.com/syntax-tree/mdast-util-gfm-autolink-literal#compatibility. Sadly, Safari is more often than not, more recently, the place where things break first.

You can indeed use older versions if you want to.

[vktrl]

“Backwards compatible” to what? The stone age? I don’t think it is reasonable to be compatible with ancient things.

Safari 16.4 has only been out for 1.5 years. It's not from the stone age, and people are using it whether we like it or not.

I don't think it's unreasonable to ask for compatibility that goes back a little further than 2023. Especially if the solution is trivial and can't be polyfilled.

You can indeed use older versions if you want to.

I don't want to, but I'm forced to. This isn't something I don't have control over because it has to run client-side. In a perfect world people would keep their devices up to date, but alas.

[wooorm]

Why do you think it’s trivial to solve?

You are of course right that the stone age was not 1.5 years ago.
However, you do understand that there is a point, somewhere, right?
There are also people that advocate the inverse of you: to not support old things.

When we cut releases, we drop support for old things. This is a breaking change that was communicated: https://github.com/syntax-tree/mdast-util-gfm-autolink-literal/releases.

[vktrl]

Why do you think it’s trivial to solve?

Because it's just one line in this commit.

You are of course right that the stone age was not 1.5 years ago. However, you do understand that there is a point, somewhere, right? There are also people that advocate the inverse of you: to not support old things.

There absolutely is a point somewhere, but is this really it? Breaking a recent browser with no workaround available because an improved regex pattern shaves off ~0.025ms when matching 5000 character strings?

[ChristianMurphy]

There absolutely is a point somewhere, but is this really it?

It is

a recent browser

A browser version which is no longer supported by Apple

[ChristianMurphy]

no workaround available

There are a number, you can hold on the older version of the package.
Try other transpiler/polyfills.
Or patch the old regex in if you want things to run slower https://github.com/ds300/patch-package#readme

[ChristianMurphy]

My stance is pretty simple, if the world's richest company doesn't have time or money to support a version of their official and licensed product.
I don't have time to support it for free in my personal time.

[0xd8d]

My stance is pretty simple, if the world's richest company doesn't have time or money to support a version of their official and licensed product. I don't have time to support it for free in my personal time.

Dismissing users on iOS < 16.4, which is still a fairly recent version, feels like an arrogant decision. It’s frustrating to see this issue brushed off when a simple regex tweak could easily prevent the crashes users are facing.

To make matters worse, this was a 2.0.0 to 2.0.1 update. A patch release should never introduce breaking changes. Dropping support for a significant chunk of users and telling developers to downgrade or deal with it isn’t just unreasonable, it’s irresponsible.

[wooorm]

The breaking change happened in v2; nothing is brushed off, it was communicated; it’s not simple to change

[vktrl]

The breaking change happened in v2;

No, it happened in 2.0.1 with this commit as pointed out previously. 2.0.0 works fine.

it was communicated;

There's no mention of this in the readme or release notes.

it’s not simple to change

It is, but you've dug in and don't want to. It's just one line. I ran some benchmarks and the only tradeoff is shaving off fractions of milliseconds.

It's fine if you don't want to support Safari out of spite. It's your library and your choice. @ChristianMurphy was very straightforward about this and I got my answer.

I don't understand why you're gaslighting us over the facts though @wooorm?

[0xd8d]

The breaking change happened in v2; nothing is brushed off, it was communicated; it’s not simple to change

It’s one thing to drop support for older browsers, but it’s another to ignore valid concerns when the fix is right in front of us. The fact that this issue popped up in 2.0.1, not in v2, shows this wasn’t a properly communicated breaking change. No one should have to comb through commits to figure out why a patch release suddenly breaks their app.

Saying the fix isn’t simple feels like an excuse when it’s a straightforward regex adjustment. We’re talking about preventing crashes for a significant number of users on Safari, and the performance hit is minimal at best.

[ChristianMurphy]

I understand the frustration that many users have brought up in this thread, and I want to offer some clarity from my perspective.

First, it’s important to remember that the project's compatibility scope explicitly targets ES2022. The use of newer regex features like negative lookbehinds fits within that standard. Introducing features that align with the support matrix is not a breaking change and does not require special communication or break semantic versioning rules. Maintaining backward compatibility with older browsers, like Safari versions before 16.4, was never intended as a priority for this version.

The suggestions made, such as using tools like Babel or holding on to a prior version of the package, are not dismissive. They are practical options to meet the needs of projects requiring broader compatibility. I understand that polyfills and transpilers are not perfect solutions in every scenario, but they are part of the ecosystem's flexibility to bridge the gap between modern and legacy environments.

The comment about Apple no longer supporting Safari versions before 16.4 is significant. These versions are not receiving updates, which means users of those versions are already vulnerable to other issues. While I sympathize with the need to accommodate users restricted to older devices or browsers, it is also important for developers to focus efforts where there is active support.

Lastly, I want to make it clear that decisions about feature changes are not about spite or dismissiveness. They are choices made considering the larger technical roadmap and the constraints of developer time and maintenance complexity. Sometimes that means drawing a line where older environments are no longer supported.

The option to use an older version or a different configuration remains open for those needing it. Moving forward, embracing the latest standards is part of progressing in a landscape where technology evolves quickly. Thank you all for sharing your views. I respect the differing perspectives here, and I hope this helps explain the rationale behind the choices made for this project.

[0xd8d]

I understand the frustration that many users have brought up in this thread, and I want to offer some clarity from my perspective.

First, it’s important to remember that the project's compatibility scope explicitly targets ES2022. The use of newer regex features like negative lookbehinds fits within that standard. Introducing features that align with the support matrix is not a breaking change and does not require special communication or break semantic versioning rules. Maintaining backward compatibility with older browsers, like Safari versions before 16.4, was never intended as a priority for this version.

The suggestions made, such as using tools like Babel or holding on to a prior version of the package, are not dismissive. They are practical options to meet the needs of projects requiring broader compatibility. I understand that polyfills and transpilers are not perfect solutions in every scenario, but they are part of the ecosystem's flexibility to bridge the gap between modern and legacy environments.

The comment about Apple no longer supporting Safari versions before 16.4 is significant. These versions are not receiving updates, which means users of those versions are already vulnerable to other issues. While I sympathize with the need to accommodate users restricted to older devices or browsers, it is also important for developers to focus efforts where there is active support.

Lastly, I want to make it clear that decisions about feature changes are not about spite or dismissiveness. They are choices made considering the larger technical roadmap and the constraints of developer time and maintenance complexity. Sometimes that means drawing a line where older environments are no longer supported.

The option to use an older version or a different configuration remains open for those needing it. Moving forward, embracing the latest standards is part of progressing in a landscape where technology evolves quickly. Thank you all for sharing your views. I respect the differing perspectives here, and I hope this helps explain the rationale behind the choices made for this project.

Yes, this project targets ES2022, but the reality is that this change broke things for a huge number of users still on Safari < 16.4. You can argue all day about technicalities and semantic versioning, but when the end result is crashes and broken apps, it’s a breaking change. Period. And in a patch release like 2.0.1, which developers expect to be stable, this kind of oversight isn’t just frustrating, it’s a major failure in communication and responsibility.

Telling developers to either roll back to an older version or use Babel isn’t a “solution.” It’s a cop-out. Not everyone has the flexibility to introduce complex build setups just to accommodate a change that could easily be fixed with a single line tweak. Why should the burden be on us to patch a simple regex issue that your team introduced in the first place?

And as for dismissing Safari < 16.4 because Apple doesn’t support it anymore, that’s a weak excuse. Just because Apple moves on doesn’t mean the rest of the world does, and pretending those users don’t exist doesn’t magically make the problem go away. We’re not talking about browsers from a decade ago, we’re talking about versions still actively used by millions. Writing them off like they don’t matter is irresponsible.

Your stance on “embracing the latest standards” feels more like stubbornness than progress. This isn’t about evolving technology, it’s about prioritizing the community that depends on your library. Developers trusted your package, and now they’re dealing with unnecessary crashes because you refuse to address an easily solvable issue.

The fix is trivial, the impact is massive, and the refusal to handle this properly is a clear signal that the user base isn’t being considered. If the goal is to alienate developers and break apps, you’re doing a great job. If not, this really needs to be addressed, not dismissed with empty justifications.

[ChristianMurphy]

I appreciate your perspective and the time you've taken to lay out your concerns. Let me respond in kind, acknowledging both the technical realities and the broader considerations at play.

First, this project, like many others targeting modern JavaScript standards, follows a well-defined compatibility matrix. It’s true that users of Safari < 16.4 have experienced issues, but the decision to target ES2022 is not arbitrary. It's based on the desire to push forward and leverage features that improve performance, maintainability, and long-term viability of codebases. This benefits the broader community, millions of users who appreciate faster load times and more efficient code execution.

Regarding the patch update, it's worth remembering that "stable" doesn't always mean "unchanged forever." Stability in software is as much about keeping up with the standards as it is about consistency. We chose to implement a feature that aligns with ES2022, which is where the broader JavaScript ecosystem is headed. A move towards newer standards is essential for the health of the ecosystem. Introducing transpilers or polyfills to accommodate those browsers is not an unreasonable ask. It's a well-established practice in the development community. Adopters need to adapt to the standards or use the tools available, instead of expecting those moving forward to hold back for a few who haven’t kept pace.

You mentioned that the solution is trivial. But let’s be clear, what might look like a trivial regex tweak isn’t just about altering a line of code. It's about the implications for performance and maintainability for the vast majority of users. The current implementation provides meaningful gains, even if those gains seem small to you. However, when multiplied across millions of uses, these incremental improvements can significantly impact the efficiency of applications. Asking us to revert a valuable enhancement to accommodate older, unsupported environments is the very thing that holds back progress. We can't let decisions for the many be dictated by the few who are unwilling or unable to adapt their tools.

On the topic of maintaining backward compatibility, I have to say it's a bit disappointing to see developers who have never contributed to this project or even to open source in general become so vocal about demanding changes. Open source is built on collaboration and contribution. If this library truly matters to you, there are avenues for engaging constructively, whether by contributing code, proposing meaningful improvements, or even adding documentation to help others navigate these changes. Instead, I see repeated calls to "fix this trivial issue" without an offer to be part of the solution. Perhaps it is easier to criticize than to contribute.

As to those personal remarks about "stubbornness" or implying this stance is irresponsible, I would suggest considering the broader picture. The community relies on maintainers, many of whom do this work in their personal time, not just to maintain stability but also to drive innovation. If the richest companies out there have moved on from supporting these older environments, it's not a trivial ask for open-source maintainers to spend their limited time and resources filling in those gaps.

Lastly, I genuinely want what's best for developers using this library. You always have options, whether that means staying on an older version, using a transpiler, or even forking the library and making the changes yourself. Those are not dismissive responses. They are practical realities in the world of software development. The commitment to progress means making choices that sometimes leave legacy systems behind, but ultimately pave the way for a more robust, capable, and efficient ecosystem.

The message is clear: progress comes with change, and embracing that is a responsibility we all share.

[vktrl]

We can't let decisions for the many be dictated by the few who are unwilling or unable to adapt their tools.

If the richest companies out there have moved on from supporting these older environments, it's not a trivial ask for open-source maintainers to spend their limited time and resources filling in those gaps.

I agree with this sentiment when it comes to dev tooling, but we can't push updates to client devices. I did a quick check and it looks like about 5% of my users on iOS are affected by this.

It's weird to frame it like it's somehow supporting Apple and their shitty browser vs the actual real-world users who are using older devices for one reason or another. I try to use the latest standards possible, all in on ESM, etc, but I choose 5% of end-users being able to use my software over "embracing progress and change" every time.

First, this project, like many others targeting modern JavaScript standards, follows a well-defined compatibility matrix. It’s true that users of Safari < 16.4 have experienced issues, but the decision to target ES2022 is not arbitrary.

This has nothing to do with ES2022. It's a regex feature that was introduced in Node 8 and in Chrome in 2017. The real issue here is Safari being the modern IE and giving us another edge case to handle.

All solutions have tradeoffs:

a. Revert the change in the library and trade a little performance for compatibility.
b. Add an escape hatch to allow usage of the old regex for compatibility, increasing code complexity.
c. Have library consumers deal with it. Tradeoff being developers having to add more unmaintainable jank to their tooling until the market share drops low enough to warrant kicking out the last few who haven't upgraded.

Again - I'm fine with your decision, I have a fix in place. I understand that they are MY users not yours, and you have no obligation support them. What really annoys me is not acknowledging and misrepresenting what the issue is and what can be done about it. "Fuck Safari, you deal with it" is much less insulting to me, personally.

[ChristianMurphy]

It's weird to frame it like it's somehow supporting Apple and their shitty browser vs the actual real-world users who are using older devices for one reason or another. I try to use the latest standards possible, all in on ESM, etc, but I choose 5% of end-users being able to use my software over "embracing progress and change" every time.

I appreciate your acknowledgment that there are still real users on older Safari versions, and yes, even some adopters have users on actual IE. We all know the range of environments out there is diverse, and the challenge lies in making technology work across that spectrum.

For over a decade, developers have been writing in modern JavaScript and using tools like Babel to downlevel it for older browsers. This is not a new concept. It's how the ecosystem has operated and thrived, allowing developers to use the best tools available while meeting the needs of users on older devices. My frustration here is that you, @vktrl, seem to want to avoid acknowledging this very simple, well-established workflow. Instead, there's a focus on complaining about the extra steps rather than just taking the time to configure the tools to do the job.

There is no need to revert the change. The solution is simple, use the existing tooling to downlevel to whatever browser versions you need for your users. This is precisely what those tools are made for. Developers using modern standards have always needed to ensure compatibility through these tools. Expecting a library to carry that burden by itself, especially when the tools to bridge that gap are readily available, is unreasonable.

---

What really annoys me is not acknowledging and misrepresenting what the issue is and what can be done about it. "Fuck Safari, you deal with it" is much less insulting to me, personally.

I do prefer to keep things professional, but since it seems my points aren't landing clearly, let me spell it out in the terms you, @vktrl, apparently need. Know that these are said with kindness not malice: stop bitching and configure your damn build tools already. ❤️

---

I appreciate the conversation, and I hope my points are clear. The responsibility here lies in adapting your build process to meet the needs of your users, just like we've all done for years. There’s no reason to drag this out, configure your tools and move forward.

If anyone has questions on how to configure their build tools or wants to discuss approaches for specific use cases, the discussion forum is open to questions and ideas. I’m happy to help where I can, as long as the conversation stays focused on productive solutions.

[ChristianMurphy]

@DaniumX my point to you remain unadressed. If you don't have anything meaningful to add, don't spam the thread.

[farzadso]

I couldn't figure out a way to pollyfill this in a modern Next.js app. Is there any chance anyone could help with that?
Babel is not an option, as Next.js uses SWC now.

[neil-morrison44]

Speaking as someone who’s had users report errors on this, pinned to 2.0.0 to fix it, then forgot & accidentally updated to 2.0.1…

I don’t think anyone’s suggesting an approach like requiring support for Node v6.
However, given that dev tooling (to my knowledge) can’t rewrite / polyfill regexes & the affected versions of Safari are still out there - in my case it’s the system WebView which isn’t updated when Safari is.

It would be nice if there was some sort of middle ground, maybe a one-time on-init feature-detection on the lookbehind that’d take unsupported browsers through the slow path & leave modern browsers as they are.

If you want, you can say whether you’d be willing to accept a PR with that & have someone whose users are running into the bug submit one.

[wooorm]

The statements

the affected versions of Safari are still out there

And

requiring support for Node v6

Conflict. Node 6 is out there. Old versions of Safari will always be out there. The previous major (v1) was compatible with Node 12. The current v2 is compatible with Node 16. This is intentional. You can still use old things. Risks apply.

For “middle ground”, I already said things in the above thread about it.

[neil-morrison44]

I’m assuming that not many people have had issues with the Node 12 -> Node 16 requirement, so it’s not really comparable.

The link on the “Node 6” comment was just showing the extent some maintainers go to to prevent these sorts of issues.

I’m taking from your comment that you’re not interested in receiving PRs which would fix this issue that people are running into (which doesn’t appear to be fixable via babel / polyfill)?

[wooorm]

You misconstrue. Please take some time to read through what was said. Particularly #10 (comment) and #10 (comment).

The link on the “Node 6” comment was just showing the extent some maintainers go to to prevent these sorts of issues.

Regex lookbehind is from Node 8. You are asking us to be almost compatible with Node 6.

[neil-morrison44]

It’s browsers rather than node versions I care about, for my use case this library is running within an operating system web view which the user can’t manually update. Meaning I’m stuck pinning to v2.0.0 until I want to drop support for macOS 13.

Here’s the facts as I see them, please correct me when I’m wrong:

• Users are running into issues due to this change
• Developers (working on both open source & paid) are arriving to this issue after discovering it somewhere deep in a dependency tree, more will likely come. For a while, until users upgrade.
• The change is for performance reasons, with no functional difference
• There isn’t a way to polyfill or to set babel / other tools to rewrite the regex in a way that doesn’t contain the lookbehind
• There is a way to detect if the user’s browser supports lookbehind & have engines which don’t support it use the “slow” path while not affecting the fast path.

I’m not looking for you to do free work, just trying to find out if you’d be open to receiving a PR that fixes this.

[ChristianMurphy]

@neil-morrison44 please see the conversation, I'm getting tired of having to repeat this again for every new person who join the thread.
Your points have been addressed at length and repeatedly.

Some highlights

Meaning I’m stuck pinning to v2.0.0

It is perfectly okay and valid to pin an older version until your users can upgrade.

There isn’t a way to polyfill

There is, and has been for over a decade:
https://github.com/beaugunderson/xregexp-lookbehind
https://gist.github.com/slevithan/2387872

other tools to rewrite the regex in a way that doesn’t contain the lookbehind

If you want to use new versions but patch in an old regex without polyfills.
There is https://github.com/ds300/patch-package#readme

There is a way to detect if the user’s browser supports lookbehind & have engines which don’t support it use the “slow” path while not affecting the fast path.

It is possible, that is what build tools and polyfills exist for, if you don't like the existing ones, you are welcome to create a new and better one that suits your needs.

[neil-morrison44]

I have read the conversation, including the massive LLM comments which - frankly - came off really condescending to people coming here after their users are encountering runtime issues. However I was choosing to write in good faith hoping for a similar response.

Your polyfilling suggestion doesn't make any sense at all, you're not using xregexp

mdast-util-gfm-autolink-literal/lib/index.js

Line 135 in 2402c21

[/(?<=^|\s|\p{P}|\p{S})([-.\w+]+)@([-\w]+(?:\.[-\w]+)+)/gu, findEmail]

you'll be using the browser's native RegExp implementation - hence the problem.

Unless you're suggesting we write new build tools which find the regex with the lookbehind in it & replace it with xregexp & that xregexp polyfill?

Forgive me if I'm wrong - but it seems like the response you'd get from googling "regex lookbehind polyfill" without checking if it's actually applicable to this situation.

Speaking personally, and you are of course free to maintain your repo however you want, but I'd have made the change conditional after the first few reports of runtime issues - if only so you wouldn't have to deal with people raising issues, which there'll likely be more, until Webkit <16.3 usage drops out completely.

[ChristianMurphy]

I have read the conversation, including the massive LLM comments

Not LLM generated just articulate.
Which I am being rapidly reminded is not the vibe of new devs and devs who don't do testing, currently joining this thread.

came off really condescending to people coming here after their users are encountering runtime issues.

I'm sorry so many people don't read the browser matrix or feel the need to test before releasing to production for their users.
Your feelings of frustration are valid, but misdirected.

Unless you're suggesting we write new build tools which find the regex with the lookbehind in it & replace it with xregexp & that xregexp polyfill?

Still yes, that is what Babel, SWC, and transpilers do.
Your build tool of choice doesn't have an existing plugin, you are welcome to make one.

Speaking personally, and you are of course free to maintain your repo however you want, but I'd have made the change conditional after the first few reports of runtime issues - if only so you wouldn't have to deal with people raising issues, which there'll likely be more, until Webkit <16.3 usage drops out completely.

Thank you for your feedback, our support matrix is clearly stated, and remains the same.
You are welcome to use the previous major which does include support for said version of WebKit.

[graysonhicks]

Just noting how much time, annoyance and broken user experiences were spent on this because a patch version deep in the dep tree released a breaking change.

Now we have a pin for a buried dep indefinitely. The response here should have been:

"Oops! We messed up. We want to support ES2022, and were excited to make this improvement, but seeing as it came over in a patch release and broke many user and developer's experience, we are going to revert it. The next major release will include this change, thanks!"

[ChristianMurphy]

@graysonhicks We only supported ES2022 in this major from the start.
The difference you see between the patches is a failing in the build tools used on your project, not in communication of what version of JS is supported.

[graysonhicks]

2.0.0 worked, 2.0.1 didn't.

[ChristianMurphy]

No
Read the thread this has been discussed at length.

[neil-morrison44]

That's a good point, makes the

...new devs and devs who don't do testing, currently joining this thread.

insult towards all the developers (I see there's more) who've run into this issue due to this particularly jarring, there isn't an expectation of having to do testing for a x.x.1 release. People would, likely, be more forgiving if it happened in 2.0.0 itself.

[graysonhicks]

@ChristianMurphy No? Then, please link me the line in 2.0.0 that caused this. I have read the thread, I understand the issue. The breaking change was introduced in 2.0.1.

[ChristianMurphy]

There were breaking changes in 2.0.0 raising dependency and ES versions your build tools smoothed over those, but not the regex one.

[ChristianMurphy]

insult towards all the developers (I see there's more) who've run into this issue due to this particularly jarring, there isn't an expectation of having to do testing for a x.x.1 release.

Your browser is explicitly outside the supported matrix for this package and has been for a while.
So yes, you do need to test.

And even if it were in matrix.
You are the maintainer of your own browser matrix and the steward for your own product. You need to test the code you are using is compatible for your users.

There’s no insult here, just an expectation you understand your responsibility and take competent steps to resolve it.

Some solutions are articulated here: #10 (comment)

To be extra clear, the compenent step is not attacking the open source maintainers who gave you free code and free support, because you feel inconvenienced.

---

A friendly reminder there is a code of conduct https://github.com/syntax-tree/.github/blob/main/code-of-conduct.md
A lot of frustrated folks are toeing the line of what is allowed.
Spamming or Trolling this thread, or issues as a whole, will lead to bans from accessing the support system.

---

If you have questions on how to do so the discussion forum is open https://github.com/orgs/syntax-tree/discussions/categories/q-a

I understand folks are confused and frustrated, and I empathize.
That doesn't change the support matrix for this module.