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

block and inline are declared to TypeScript as exported, but are never exported #3426

Closed
darkuranium opened this issue Aug 23, 2024 · 3 comments · Fixed by #3427
Closed

block and inline are declared to TypeScript as exported, but are never exported #3426

darkuranium opened this issue Aug 23, 2024 · 3 comments · Fixed by #3427
Labels
category: types L2 - annoying Similar to L1 - broken but there is a known workaround available for the issue

Comments

@darkuranium
Copy link

Marked version: 14.0.0

Describe the bug
marked.d.ts marks both block and inline as export declare const ..., implying they are available for import. However, neither symbol is actually available (in neither CJS, ESM, or UMD form).

Note marked.d.ts declares both as exported:

export declare const block: {
...
export declare const inline: {
...

But marked.esm.js (or .cjs & .umd.js files) do not in fact export it:

export { _Hooks as Hooks, _Lexer as Lexer, Marked, _Parser as Parser, _Renderer as Renderer, _TextRenderer as TextRenderer, _Tokenizer as Tokenizer, _defaults as defaults, _getDefaults as getDefaults, lexer, marked, options, parse, parseInline, parser, setOptions, use, walkTokens };

To Reproduce
Simply install [email protected], and write the following (TypeScript!) file:

// Okay as per TypeScript/tsc, but we get a runtime error: `SyntaxError: The requested module 'marked' does not provide an export named 'block'`
import { block, inline } from 'marked';
console.log(block, inline); // is *not* available

Expected behavior
The type declarations should match the actual exports --- either marked.d.ts should not declare those types as export, or (ideally) block & inline should actually be exported.

@UziTech
Copy link
Member

UziTech commented Aug 23, 2024

Nice catch! 💯

I don't think those should be exported since they are an implementation detail and they can change without releasing a major version.

@darkuranium
Copy link
Author

darkuranium commented Aug 23, 2024

For what it's worth, the reason I need these is to be able to override every single renderer, to output a token tree instead of HTML. Can you think of a better way of doing that?

Edit: Is hooks.processAllTokens is guaranteed to receive exactly the set of the root tokens in the initial call, i.e. if I don't recurse with this.processAllTokens(token.tokens)? If so, than that would resolve my conundrum.

@UziTech
Copy link
Member

UziTech commented Aug 23, 2024

marked.lexer(src, options) will return a token tree.

Yes, hooks.processAllTokens is the way to get access to the output of marked.lexer before it goes to walkTokens then to marked.parser to be converted to html.

marked/src/Instance.ts

Lines 307 to 321 in 0076503

if (opt.hooks) {
src = opt.hooks.preprocess(src) as string;
}
let tokens = lexer(src, opt);
if (opt.hooks) {
tokens = opt.hooks.processAllTokens(tokens) as Token[] | TokensList;
}
if (opt.walkTokens) {
this.walkTokens(tokens, opt.walkTokens);
}
let html = parser(tokens, opt);
if (opt.hooks) {
html = opt.hooks.postprocess(html) as string;
}
return html;

@UziTech UziTech added L2 - annoying Similar to L1 - broken but there is a known workaround available for the issue category: types labels Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: types L2 - annoying Similar to L1 - broken but there is a known workaround available for the issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants