Incompatibility with esNext Syntax in marked.js Bundle

[nbutmickey]

What pain point are you perceiving?.

1. we've observed that the output bundle from marked.js contains esNext syntax like ?. or ??. It's unreasonable and irresponsible for such a widely used library to include syntax incompatible with older browsers. detail code
2. upon inspecting the source code, it appears that the bundle is generated using Rollup with only the Terser plugin configured, without compatibility measures for advanced syntax.

Describe the solution you'd like

1. configuring the Buble plugin for Rollup to perform code transpilation.
2. remove the code involving the ?. or ?? syntax and implement suitable compatible code.

Sure, I think option one can be a one-time solution, but it may lead to an increase in package size. Option two might be a bit more complicated as it requires replacing each one individually, and it's essential to ensure that subsequent code doesn't introduce similar syntax.

[UziTech]

Option 1 is already available for your project. You can use Babel to compile marked to whatever version of es you need.

We decided to drop support a while ago for es5 since the es5 version of marked was about 30% slower than esNext.

It is unreasonable to believe marked knows what is best for all of its users. If you want speed you can use the esNext version. If you need wider support you can compile it with Babel.

[nbutmickey]

Option 1 is already available for your project. You can use Babel to compile marked to whatever version of es you need.

We decided to drop support a while ago for es5 since the es5 version of marked was about 30% slower than esNext.

It is unreasonable to believe marked knows what is best for all of its users. If you want speed you can use the esNext version. If you need wider support you can compile it with Babel.

1. Do you have relevant data supporting the conclusion that the ES5 version of 'marked' is 30% slower than the ESNext version?

2. I believe that as a library with such broad coverage, it should address compatibility issues. Assuming I create a library 'A' based on 'marked,' users of my library 'A' will install 'marked,' but if they don't use Babel to transpile ESNext code, issues may arise. We can't require all users to mandate Babel for compilation. This conclusion applies to library 'A' as well, and it's impractical to expect all authors of library 'A' to transpile your code.

In summary, I think it's crucial for an open-source library to handle compatibility issues well, or it can bring endless problems to developers.

[UziTech]

Do you have relevant data supporting the conclusion that the ES5 version of 'marked' is 30% slower than the ESNext version?

No, I encourage you to test it yourself. If you find a way to speed up marked, we are always accepting PRs 😁👍

In summary, I think it's crucial for an open-source library to handle compatibility issues well, or it can bring endless problems to developers.

I think you are confusing open-source software with software that developers get paid to maintain. Unfortunately all of the maintainers of marked help in our free time. As such we do not have time to handle compatibility issues well. Hence passing off the work of compiling to the users.

If you know of a better way to do it we are always accepting PRs 😁👍

[nbutmickey]

Understood. I might initiate a pull request.

[jjblumenfeld]

Option 1 is already available for your project. You can use Babel to compile marked to whatever version of es you need.

Can you describe a bit more how to implement this solution?

[UziTech]

@jjblumenfeld you can use babel to transpile the code you send to your users if you need to support older browsers. You may need to tell it to transpile node_modules modules depending on your settings.