Separates web and node bundles #43
Conversation
There was a problem hiding this comment.
I guess I did not describe this adequately in #42; Webpack stuff is not what I was referring to by “separate entrypoints.” I don’t think anything about Webpack should be involved in publishing to NPM at all.
This was meant to be about package entrypoints, which are a package.json feature. You can define different code for browser-based packagers (e.g. Webpack, Rollup, etc.) and non-browsers (Node.js runtime, Bun, etc.) to pick up when importing/requiring the module, rather than different builds that have to be run before publishing. I don’t think we should need any kind of build step here for publishing on NPM and for library/CLI usage.
In general I’d also prefer to see rehype-parse used as well, rather than adding new steps to parsing by bringing in JSDOM (unless there’s a compelling reason not to).
| import { convertToMarkdown } from './lib/convert.js'; | ||
| import jsdom from 'jsdom'; | ||
|
|
||
| global.DOMParser = new jsdom.JSDOM().window.DOMParser; | ||
| global.convertToMarkdown = convertToMarkdown; |
There was a problem hiding this comment.
Was there a reason not to use retype-parse here instead, which has the same interface as rehype-dom-parse, rather than adding extra steps and opportunities for problems (e.g. script injection issues)?
| "path-browserify": "^1.0.1", | ||
| "rehype-dom-parse": "^4.0.2", | ||
| "rehype-remark": "^9.1.2", | ||
| "remark-stringify": "^7.0.4", | ||
| "unified": "^10.1.2", | ||
| "unist-util-visit": "^4.1.0", | ||
| "utf-8-validate": "^5.0.10", |
There was a problem hiding this comment.
Is this being used anywhere? What was it added for?
No description provided.