-
Notifications
You must be signed in to change notification settings - Fork 39
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
Publish package on NPM #42
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! |
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.
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 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. |
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-parse
package 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-parse
instead.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: