configure Babel in esm packaging config

[lisnote]

Babel is not only needed in UMD packagin, but also in ESM.

I'm notice this commit, #1572,
Use Babel's loose mode for shorted & more performant code
I couldn't agree more with that statement,
and also think that use Babel translate javascript to esm module would also have the same benefits

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
marked-website	✅ Ready (Inspect)	Visit Preview	May 6, 2022 at 5:53PM (UTC)

[UziTech]

Babel is not only needed in UMD packagin, but also in ESM.

Why is it needed in ESM?

[lisnote]

In short : Improving stability

thanks for your reply.

I think the ESM module building needs Babel for the following reasons.

1. Compatible with almost all modern browsers

   Modern browsers kernel have so many types, we use some features in marked code but many browser are not support. Babel could help us to support these browsers

2. You can still use the new feature of javascript

   For the code, we want to use the new feature, but for the generated code, we hope it can be stable running, Babel can do it.

3. No new dependencies are added

   Babel is already in the library's dependencies, it has use for translated the UMD and CJS modules, so no new dependencies are added.

4. ESM module require Babel more than UMD and CJS module

   Compared to the relatively uniform javascript back-end, the front-end browser environment is even more chaotic, however engineers wish everyone have the same experience,

   we can use the UMD or CJS package in back-end, but when we want to use modularization development, the ESM module is the only option.

   Engineers can change their environments, but they can't force users to use their specified browser.

   While any one can solve this problem during development, I wish this problem had never happened.

   Why use Babel to translate UMD and CJS, That's why using Babel to translate ESM.

5. Reduce unnecessary headaches for developers

   Although developers can use Babel in their own environment to translate marked again, or even rewrite a markdown parser with javascript, but that's a bit unnecessary.

   And I think stability is very important for a library, use Babel to translate the ESM module will make developers more relaxed

6. Resolve some closed issues but I don't think the problem was resolved

   Such as Alternative to unicode property escapes regular expression? #2339 , this issuss has been closed but I think that is not solve problems.

   you replied with "I don't think we are interested in supporting old versions of browsers",

   that's right, I also don't want to adapt to an older browser like IE, but this problem is actually bigger than he said.

   Not only old version Firefox Browser, some latest versions of popular browsers also don't support.
   Such as the mobile version of UC Browser who has been downloaded 222,141,748 times in Google Play
   UC Browser does not support Unicode Property, you will get a error when you run the following code in UC Browser.

   import { marked } from './marked.esm.js';
   marked.parse(`_r`)
   // error : Uncaught SyntaxError: Invalid regular expression: /[\p{L}\p{N}]/: Invalid property name in character class
   

   use Babel to translate ESM module will solve this problem effectively.

[UziTech]

UMD is meant to be used client side. The best client side option would be to use the minified file marked.min.js which is minified from UMD. See Browser Usage

The point of the esm file is so developers can get the speed advantages of modern JavaScript. Using babel (even in loose mode) slows it down slightly.

[UziTech]

Perhaps the solution could be to create a new file like marked.es5.esm.js. That prevents slowing down the regular users and provides a way to use esm in every browser.

[lisnote]

Thanks for your reminding. I have understood the differences between the versions of marked before I asked the question.

Compiling with iife format can also reduce the space of marked.min.js 0.2KB or so.

But use the UMD or IIFE package is more troublesome in modular development.

My current solution is to build the ES5 version ESM.

And copied a copy from @types/marked as declaration file of the custom marked.

so that I can use custom marked while continuing to code in TypeScript

marked.min.js is indeed the client's recommended option,

but limited in common front-end development,

In universal front-end project, a better way is import ESM and work with TypeScript to reduce errors

Unfortunately, I am.

Perhaps the solution could be to create a new file like marked.es5.esm.js

Nice solution!

I would appreciate it if 'marked. es5.esm.js' exists.

If two ESMs are included in a package, the TypeScript declaration file need modify slightly.

please modify it as well.

thanks and good night~

[UziTech]

Typescript types are maintained by DefinitelyTyped. You will need to create a PR there to change the types.

[lisnote]

I see, thank you for your help.