fix: make "ipfs resolve" cli command recursive by default

[yusefnapora]

This changes the default behavior of the jsipfs resolve cli command to be recursive by default. Closes #3692.

# in packages/ipfs
node src/cli.js resolve /ipns/ipfs.io
/ipfs/bafybeiagozluzfopjadeigrjlsmktseozde2xc5prvighob7452imnk76a

BREAKING CHANGE: resolve is now recursive by default

[yusefnapora]

cc @lidel / @olizilla since I haven't got my permissions sorted yet and can't request a review directly 😄

[lidel]

Thanks! CI is green, but it also means that we have no tests for this 😅

Perhaps you could add DNSLink test to safeguard of the default behavior in ipfs-cli/test/resolve.js?

[yusefnapora]

I updated the tests a bit in ipfs-cli/test/resolve.js in the last commit, but it doesn't really cover the DNSLink issue. These tests just check that ipfs.resolve gets called with the right options for a given cli invocation, so there's no real lookup happening that we can validate.

@lidel Do you know if there's an end-to-end test for the resolve method elsewhere?

[achingbrain]

@yusefnapora the intergration-style tests that would actually do DNS lookups are in the interface-ipfs-core tests - please add new tests for this there.

[yusefnapora]

@achingbrain thanks for the pointer! There was already a test in there for the recursive case, but since recursive is the default, there was no test that covered the non-recursive case.

I added a test for recursive==false, which flushed out an issue. resolve was rewriting the "scheme" portion of the resolved name to /ipfs, even if it actually starts with e.g. /ipns.

So if e.g. you have a recursive IPNS record like:

/ipns/foo -> /ipns/bar -> /ipfs/bafyxzy...

calling resolve('/ipns/foo', { recursive: false }) was returning /ipfs/bar instead of /ipns/bar.

Yay for tests :)

[lidel]

Lgm, tests seem to fail for unrelated reasons, @achingbrain mind confirming and doing final review in spare time?

[achingbrain]

This is great, but the newly added test is failing in CI

[achingbrain]

Still failing:

ipfs:   1) interface-ipfs-core tests
ipfs:        .resolve
ipfs:          should resolve IPNS link non-recursively if recursive==false:
ipfs:      Error: record requested for QmYQ4diQzAKmE7PFGY7fbREgiuu4kCcqo88oR7TGrMgv53 was not found in the network
ipfs:       at IpnsResolver._resolveName (/home/travis/build/ipfs/js-ipfs/packages/ipfs-core/src/ipns/resolver.js:102:23)
ipfs:       at async IpnsResolver.resolver (/home/travis/build/ipfs/js-ipfs/packages/ipfs-core/src/ipns/resolver.js:74:17)
ipfs:       at async IpnsResolver.resolve (/home/travis/build/ipfs/js-ipfs/packages/ipfs-core/src/ipns/resolver.js:52:17)
ipfs:       at async IPNS.resolve (/home/travis/build/ipfs/js-ipfs/packages/ipfs-core/src/ipns/index.js:101:22)
ipfs:       at async resolve (/home/travis/build/ipfs/js-ipfs/packages/ipfs-core/src/components/name/resolve.js:84:19)
ipfs:       at async resolve (/home/travis/build/ipfs/js-ipfs/packages/ipfs-core/src/components/resolve.js:27:24)
ipfs:       at async Context.<anonymous> (/home/travis/build/ipfs/js-ipfs/packages/interface-ipfs-core/src/miscellaneous/resolve.js:112:21)

[lidel]

@yusefnapora will you have time to push this one over the finish line?

[yusefnapora]

Sorry for letting this one dangle folks. I'll pick it back up this week

[yusefnapora]

The last few commits were me flailing to figure out a type check failure in ipfs-message-port-client that I wasn't able to reproduce locally. I finally got it to show up by installing a new version of node - I was on 14.17.0, while CI was running 14.17.1. I updated to the latest v14 release (14.17.3) and started seeing the error locally also.

The problem is that on node, setTimeout returns a NodeJS.Timeout instead of number, so typescript complains when trying to assign to a value of type number|null.

SO to the rescue with a trick to define the type of timerID as whatever the return type of setTimeout actually is.

[yusefnapora]

BTW, I think the original test failure was happening because I used the same key ID (key-name) for both of the IPNS tests. I was running each test individually locally since running the whole suite takes a while. Once I ran them all I saw an error about key-name already being registered, so I changed the second test to use a different name. CI's still running, so we'll see :)

[yusefnapora]

There's one more test failure, but this one is a module resolution failure in example code:

example-browser-browserify: > browserify src/index.js > public/bundle.js
example-browser-browserify: Error: Can't walk dependency graph: Cannot find module 'multiformats/hashes/sha2' from '/home/travis/build/ipfs/js-ipfs/node_modules/libp2p-crypto/src/keys/rsa-class.js'
example-browser-browserify:     required by /home/travis/build/ipfs/js-ipfs/node_modules/libp2p-crypto/src/keys/rsa-class.js
example-browser-browserify:     at /home/travis/build/ipfs/js-ipfs/node_modules/resolve/lib/async.js:137:35
example-browser-browserify:     at processDirs (/home/travis/build/ipfs/js-ipfs/node_modules/resolve/lib/async.js:290:39)
example-browser-browserify:     at isdir (/home/travis/build/ipfs/js-ipfs/node_modules/resolve/lib/async.js:297:32)
example-browser-browserify:     at /home/travis/build/ipfs/js-ipfs/node_modules/resolve/lib/async.js:25:69
example-browser-browserify:     at FSReqCallback.oncomplete (fs.js:192:21)

That sounds like something that fits into the "maintenance week" remit, so I'll check it out tomorrow :) That should probably go into its own PR though.

[yusefnapora]

@achingbrain it looks like the last failing test should be fixed by the work you did on #3742 😄

[achingbrain]

@yusefnapora awesome! I've restarted that bit of the build, it should pull down the updated modules and be good then.

[achingbrain]

I'm going to land this after #3556