Publish package on NPM #42
Labels
enhancement
New feature or request
Comments
|
Hey, @Mr0grog! I created a PR for the 4th task: #43 I don't have a deep understanding of node, so would love a review if there is something very wrong with this and if there are points that can be improved, before investigating further the aspect you pointed out about Thanks in advance! |
Mr0grog
added a commit
that referenced
this issue
May 1, 2023
We now have unit and end-to-end tests that run in Chrome, Firefox, and Safari using WebdriverIO. `npm test` runs both, or you can run just `npm run test-unit` or `npm run test-e2e`. They are set up as separate jobs in CI. In the future, I hope to set up Sauce or Browserstack to run these on specific browser versions rather than whatever is installed locally, but this is a start. This also includes a script to download actual Google Docs as fixtures for use in the tests, which will help keep tests accurate when Google Docs's output formats change. Update the fixture files by running `npm run download-fixtures`. It will create two fixture files for each doc: `<title>.copy.html` is the result of copying and pasting a doc (as most people normally would when using this tool) and `<title>.export.html` is the result of exporting the doc as HTML. The tests against the exported output are currently skipped, since they don't work! (I had thought they would based on discussion in a different PR, but it turns out they don't.) I've kept them here to support future work in supporting them, though. Part of #42.
Mr0grog
added a commit
that referenced
this issue
Jun 21, 2023
I think I hadn't configured this previously because of interest in publishing this as a library on NPM (#42), but to be honest I don't recall exactly. In any case, I realized today I could create separate update configuration for dev and production dependencies, which solves any issues I think I would have been concerned about. (There are no production dependencies right now, but I'll have to shift hast/unified/etc. to production to publish on NPM, at which point the separate configs will matter.)
Mr0grog
added a commit
that referenced
this issue
Jun 21, 2023
I think I hadn't configured this previously because of interest in publishing this as a library on NPM (#42), but to be honest I don't recall exactly. In any case, I realized today I could create separate update configuration for dev and production dependencies, which solves any issues I think I would have been concerned about. (There are no production dependencies right now, but I'll have to shift hast/unified/etc. to production to publish on NPM, at which point the separate configs will matter.)
|
I have the node side of this working here #84 |
|
Thanks! That’s super helpful. I left a bunch of comments on the various PRs you posted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A couple folks have expressed interest in using this package as a library and making it available on NPM (see #40, #41). Getting there requires several smaller pieces of work:
Move all reusable code into
lib/and separate it from the code that is UI/webpage-centric. (Extract md conversion code from browser code for easier cli usage #40]Add changelog and tooling around proper semantic versioning.
Have at least some basic tests for the library code. (Add tests #51)
Create separate entrypoints for browser and non-browser (e.g. Node.js) runtimes. For browsers, we use the
rehype-dom-parsepackage to parse the HTML source of a GDocs document into a Rehype AST. That depends on browser built-ins that aren’t available in other runtimes, though! For non-browsers, we want to useretype-parseinstead.Determine if the package should be renamed (since it is converting GDocs-centric HTML, rather than an actual GDocs data structure).
(Maybe?) Add a basic CLI interface.
Publish v1.0.0!
The text was updated successfully, but these errors were encountered: