chore(deps): adapt to marked@12 #280
Conversation
|
Many options were removed in version 8. Also we have our own implementation of headerid, while there is a plugin for that. We could remove our code for that |
|
hexo-renderer-marked has custom implementation of many options, so it's not affected much by the breaking changes since marked 8.0. I'll check again if some options are no longer working. |
|
marked's official headerid plugin does not support headerlink like Ours: hexo-renderer-marked/lib/renderer.js Line 59 in 680f3ae Theirs: https://github.com/markedjs/marked-gfm-heading-id/blob/e214c9091ce5770b416ebede1f5076cc8026d5d7/lib/index.cjs#L107 |
There was a problem hiding this comment.
marked requires node+18 since v10.0.0 😩
We have three options:
- Bump the marked to 9.x (Do not bump 10.x+)
- Require Node.js 18.x+ (all of hexo org repositories).
- Ignore it (fortunately, tests are passing)
Personally, I think we should start to drop Node.js 14 & 16. However, we have a lot of repositories... 😫
| super(); | ||
| this._headingId = {}; | ||
| this.hexo = hexo; | ||
| function mangleEmail(text) { |
There was a problem hiding this comment.
LGTM, but why not use the plugin?
https://www.npmjs.com/package/marked-mangle
There was a problem hiding this comment.
Using the official plugin is also an option, but I think using our custom implementation would be more convenient. The official marked plugin is implemented inside the tokenizer, while we have already customized links in the renderer (for example, modifying links that start with javascript:). This way, we can simply add a handling logic for mailto: links in a similar place.
There was a problem hiding this comment.
Ideally, we could re-implement all Hexo specific feature using marked extension API.
We could even implement the old filter API on top of the marked extension API.
|
Node.js 16.x is End-of-Life since September 2023, we can consider raising the minimum supported Node.js version for Hexo-related repositories. |
I think if there are no changes of code or dependencies , then there is no need to update the version numbers of all repositories. |
I'm concerned about the tedious PRs of just rewriting 'engines' and 'CI settings' in many repositories. It may demotivate us (maintainers). I think this will be resolved in the migration to monorepo of hexojs/hexo#5273 in the future, but I don't think we can do that before the drop of Node.js 14 and 16. Anyway, I think it's okay to start to drop Node.js 14 and 16. |
|
CI is green, so adding node 20 and dropping node 14 and 16 can be done later |
|
We might consider whether we can automate the process of upgrading the Node.js version used in For example, we can use tools like https://github.com/msimerson/node-lts-versions |
|
By looking at the https://node.green website, I found that the recent Node.js versions haven't introduced many new features that are widely used. Therefore, even if marked raises its minimum supported version, it would still work fine on older versions like Node.js 14. Update: The newer version of JSDOM is incompatible with Node.js 14, as it uses an operator that is not supported. |
Marked has undergone significant upgrades in the past year (the version number quickly jumped from 4 to 12), and many old customization methods no longer apply. This pull request is intended to adapt to the new versions of marked. It's important to note that I have only ensured that all current unit tests can pass; whether it works properly in a real Hexo environment still needs further testing.
Issue resolved: #209
Issue resolved: #263