Skip to content
This repository has been archived by the owner on Mar 28, 2023. It is now read-only.

Improving types, readme & tests #85

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

corollari
Copy link
Contributor

@corollari corollari commented Sep 2, 2020

This PR will implement the changes discussed on discord:

  • Convert readme to markdown on CI
  • Generate typescript declarations
  • Initial work on improving tests

And adds a few extra fixes:

  • Fixes the example code on the readme (it was outdated)
  • Adds a type that was forgotten
  • Bumps some dependencies

Also, should I split this into multiple PRs? I thought that given that the changes made here are quite small a single PR might work best.

TS declarations

Once this (or the commit for generating ts declarations) gets merged and published as a package I'll also deprecate the DefinitelyTyped package, as it will be useless at this point.

A note on tests

On discord I mentioned that I'd start working on better tests that use a real environment, however now I think that it's best to focus my time on ln2tbtc (the submarine swaps project) to push it to mainnet. In any case, I've dusted off the previous tests and got them working again, but if you feel that they just don't add much value feel free to remove that commit.

@corollari
Copy link
Contributor Author

corollari commented Sep 2, 2020

Also, currently the typechecks done on the CI are broken, I've tried to replace the jq script with a --project flag that points to jsconfig.json but that hasn't worked (I don't know why tho)

@corollari corollari marked this pull request as ready for review September 3, 2020 09:02
@corollari corollari changed the title A few improvements Improving types, readme & tests Sep 3, 2020
@corollari
Copy link
Contributor Author

Fixed merge conflicts

@corollari
Copy link
Contributor Author

Note: f2da1ab is also applied on #91

Copy link
Contributor

@Shadowfiend Shadowfiend left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the long wait here---had a look and left some notes. This is looking awesome overall though, I think when we merge it I'll run a stable release so we have types in the main package.

- name: Install pandoc
run: wget https://github.com/jgm/pandoc/releases/download/2.10.1/pandoc-2.10.1-1-amd64.deb && sudo dpkg -i pandoc-2.10.1-1-amd64.deb
- name: Convert readme to markdown
run: asciidoctor README.adoc -b docbook -o - | pandoc -f docbook -t gfm > README.md
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I experimented with this a bit the other day---I think the move here is:

asciidoctor README.adoc -o - | pandoc -f html -t markdown_strict - -o README.md

Going through HTML seems to produce better Markdown output (e.g., it includes the Table of Contents and title) than using Docbook as the intermediary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see, that's probably better than my command since I didn't directly compare the results achieved when using different intermediary formats.

}
server: "electrumx-server.test.tbtc.network",
port: 8443,
protocol: "wss"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

"scripts": {
"test": "mocha --timeout 10000",
"lint": "npm run lint:js",
"lint:fix": "npm run lint:fix:js",
"lint:js": "npm run lint:js:eslint && npm run lint:js:types",
"lint:fix:js": "eslint --fix .",
"lint:js:eslint": "eslint .",
"lint:js:types": "!(npx tsc --allowJs --noEmit $(cat jsconfig.json | jq -r '.compilerOptions | to_entries | map([\"--\\(.key)\",.value]) | flatten | join(\" \")') src/**.js bin/**.js examples/**.js | grep \"^\\(src\\|bin\\|test\\|examples\\)/\") # comment any other passed arguments"
"lint:js:types": "!(npx tsc --allowJs --noEmit $(cat jsconfig.json | jq -r '.compilerOptions | to_entries | map([\"--\\(.key)\",.value]) | flatten | join(\" \")') src/**.js bin/**.js examples/**.js | grep \"^\\(src\\|bin\\|test\\|examples\\)/\") # comment any other passed arguments",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm here---ultimately this did end up working?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I spent several hours trying to get it to work through other methods that don't involve having to parse the .json file directly (would solve the problem on CI while simplifying the command heavily) but I couldn't get it to work, so it's still broken on CI runners.

Probably the easiest way to solve that problem would be patching/upgrading the version of jq used on CI, as that is what causes the breakage. If you feel that's a good solution I'll bundle it into this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's actually pull it to a new PR if that's okay---this one's getting big and starting to drift from coherence haha.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I spent several hours trying to get it to work through other methods that don't involve having to parse the .json file directly

Side note: I did this when I originally landed on this solution too haha. It's brutal.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's actually pull it to a new PR if that's okay

On it!

Side note: I did this when I originally landed on this solution too haha. It's brutal.

Yeah, I spent way too much time trying to get it to work with tsc's --project, which seems to be made for this type of use-cases, but while the options were correctly parsed I kept running into problems 😖

"scripts": {
"test": "mocha --timeout 10000",
"lint": "npm run lint:js",
"lint:fix": "npm run lint:fix:js",
"lint:js": "npm run lint:js:eslint && npm run lint:js:types",
"lint:fix:js": "eslint --fix .",
"lint:js:eslint": "eslint .",
"lint:js:types": "!(npx tsc --allowJs --noEmit $(cat jsconfig.json | jq -r '.compilerOptions | to_entries | map([\"--\\(.key)\",.value]) | flatten | join(\" \")') src/**.js bin/**.js examples/**.js | grep \"^\\(src\\|bin\\|test\\|examples\\)/\") # comment any other passed arguments"
"lint:js:types": "!(npx tsc --allowJs --noEmit $(cat jsconfig.json | jq -r '.compilerOptions | to_entries | map([\"--\\(.key)\",.value]) | flatten | join(\" \")') src/**.js bin/**.js examples/**.js | grep \"^\\(src\\|bin\\|test\\|examples\\)/\") # comment any other passed arguments",
"generate:types": "tsc src/*.js --declaration --allowJs --emitDeclarationOnly --outDir types"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😎

@@ -1,6 +1,6 @@
import ElectrumClient from "electrum-client-js"
import sha256 from "bcrypto/lib/sha256.js"
import { backoffRetrier } from "./backoff"
import { backoffRetrier } from "./backoff.js"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😅

import { BitcoinSPV } from "../src/lib/BitcoinSPV.js"
import ElectrumClient from "../src/lib/ElectrumClient.js"
import fs from "fs"
import chai from "chai"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We generally import these at the global level rather than invoking them on chai. Is the reason here to satisfy TypeScript? I seem to recall having run into an issue or two with TypeScript, chai, and tests, but remember figuring out how to deal with it… Knowledge that is lost but likely easily found hehe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest I don't really remember the exact reason why I went with this. I'll look into doing it in other ways 👌

@@ -467,7 +467,7 @@ export default class Client {
* @param {string} script ScriptPubKey in a hexadecimal format.
* @return {string} Script hash as a hex string.
*/
function scriptToHash(script) {
export function scriptToHash(script) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wish there was a way to export this for testing without exporting it for everyone else 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought of using something like rewire but given that this is an internal file which is not meant to be used as part of the library I thought it would be okay to just export it.

What do you think would be the best solution among these?

  • Move it into it's own file and test that directly
  • Spy on the implementation using rewire

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I should have been clearer---I'm fine with it as is, don't think we need to do any additional work right now. I've been thinking about it some more and really, it might even make more sense as a function of ElectrumClient, which is where it was in the first place. Either way, I don't think it needs any more work right now, we are past Good Enough™.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it! 👌

@corollari corollari mentioned this pull request Sep 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants