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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI deprecation warning #2797

Closed
tborychowski opened this issue May 8, 2023 · 12 comments · Fixed by #2802
Closed

CLI deprecation warning #2797

tborychowski opened this issue May 8, 2023 · 12 comments · Fixed by #2802

Comments

@tborychowski
Copy link

tborychowski commented May 8, 2023

Marked version

5.0.1

Describe the bug

Since the last upgrade (from v4.x to 5.0.1) I'm seeing the following warnings:

marked(): mangle parameter is deprecated since version 5.0.0, should not be used and will be removed in the future. Instead use https://www.npmjs.com/package/marked-mangle.
marked(): headerIds and headerPrefix parameters are deprecated since version 5.0.0, should not be used and will be removed in the future. Instead use https://www.npmjs.com/package/marked-gfm-heading-id.

I don't use the js API, just run the CLI via npm scripts.

To Reproduce

This is the command I use: marked --gfm -i CHANGELOG.md -o changelog.html

Expected behavior

No warnings :-)

@UziTech
Copy link
Member

UziTech commented May 8, 2023

In the release notes for v5.0.1 it explains why and what you can do about it.

@calculuschild
Copy link
Contributor

@UziTech Perhaps the warning messages could be more clear on this:

marked(): mangle parameter is deprecated since version 5.0.0, should not be used and will be removed in the future. Note the "mangle" parameter is historically enabled by default, but can be manually disabled, or instead use https://www.npmjs.com/package/marked-mangle.

@UziTech
Copy link
Member

UziTech commented May 8, 2023

Ya we tried to keep the warnings short.

@calculuschild
Copy link
Contributor

Do you mind if I make a PR to add those extra words? I think it might be worth the added length if it gives our users a more clear indication of what's going on.

@UziTech
Copy link
Member

UziTech commented May 8, 2023

Sounds good to me. 👍

@tborychowski
Copy link
Author

Thanks @UziTech,

I modified the command, and these 2 did the trick:

marked --no-mangle --no-header-ids ...

@danielkrajnik
Copy link

How do you configure it so --no-mangle option is used by default? I've tried setting this option to false in src/default.js, but it didn't seem to pick it up on subsequent invocations.

@tborychowski
Copy link
Author

@danielkrajnik
I use marked as CLI in scripts of my package.json, so I have sth like this:

"scripts": {
    "changelog": "marked --no-mangle --no-header-ids --gfm -i CHANGELOG.md -o docs/changelog.html"
}

@danielkrajnik
Copy link

danielkrajnik commented May 22, 2023

thanks, sorry, I may be asking wrong question, but I'm trying to install marked.js globally and configure it's default behaviour - I was hoping that it reads configuration files from some standard directory like ~/.config/markedjs or /etc/markedjs .

As a temporary workaround I've edited marked.js directly, (marked.use({mangle:false}) , but it may get reverted on the next update.

Not sure if configuring globally installed npm modules is even possible?

@tborychowski
Copy link
Author

can you not just add an alias in your shell? e.g.

alias md='marked --no-mangle --no-header-ids --gfm -i '

then you'd just use this like this:

md page.md -o page.html

@danielkrajnik
Copy link

You are right that this would work, putting it in .profile or /etc/profile would ensure that other programs would pick it up as well, but I hoped that npm had a dedicated place for these changes. It would make it easier to maintain it later on, because normally you expect all program-specific configuration to live inside .config, /etc or other standard locations. .bashrc/.zshrc is normally used only for "personal customisations" and this seems to be part of "application logic".

@UziTech
Copy link
Member

UziTech commented Jul 21, 2023

@danielkrajnik PRs are always welcome 😁👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants