Stefan Buck

Looks good to me, but can you add a test please? The tests are running two times. Once against a fixture file and a second time against the real website....

Btw the tests are failing because of coveralls.io which has an outdated configuration. I'm on it

Smart workaround, but (I'm sorry) I like @sindresorhus suggestion more. Mainly, because his suggestion is more flexible than yours. Imagine you need to spy for changes on two different container...

@josephfrazier did you spot this issue while working on OctoLinker? I'm asking, because there we're only interested in dom changes related to `#js-repo-pjax-container`. OctoLinker doesn't need to append any element...

> @stefanbuck this package moved to es modules so we'll need to start using babel if we want to update to the latest version. or we update to node.js 14...

Maybe I'm too strict, but I have a few concerns about it. First of all the `live resolver` should be reliable as possible. What if the requested package and repository...

I just remembered that the GitHub search API has a `language` filter which we can use to differentiate between different package for different languages. https://help.github.com/articles/searching-repositories/#search-based-on-the-main-language-of-a-repository

Very interesting discovery. I'm a bit hesitant to add an extra check for a few reasons: - The GitHub API rate limit for authenticated request is 5000 requests per hour....

Once this is live, we should be able to get rid off https://github.com/OctoLinker/OctoLinker/blob/343ff1e350d8c446ae3f152c747f9cf2b42331b9/packages/plugin-go/index.js#L52-L53 and use to `go` resolver all the time given that this page is hosting all packages

> move from current dir to sub dir or files not across the whole codebase just like the vscode does Can you elaborate on this please? Ideally with a step...