OctoLinker beta

[stefanbuck]

First, thank you for joining our beta.

Below, you will find the highlights as well as the installation instructions for this beta build. If you come across any issues or if you have feedback to offer, please let us know. If everything is working great, that's also nice to hear.

Highlights

• Insert real href-links which the browser understands and applies the typical options you'd expect on. So you're able to e.g. right-click and open links in a new tab/window or middle-click the links, etc.
• Prefetch all links in the background. This is actually the key which enables all those exciting improvements.
• Use the GitHub API to fetch a tree structure of the repo to resolve relative links much faster and accurate than before.
• Navigate to relative files without a full page refresh using pjax
• Expanding the diff view invokes OctoLinker again to resolve missing imports

Beta installation

Note: The beta is currently only available for Google Chrome.

1. Before installing the beta version, you need to disable or uninstall the current version of OctoLinker.
2. Install the OctoLinker beta from Chrome Web Store.

[leomoty]

The beta fixes this one too, doesn't it? #510

At least according to our conversation.

[stefanbuck]

No, it's a different issue. The import statement is divided by the expand line and therefore the regex fails over.

[leomoty]

Ah right, you didn't change anything about the parsing of that block?

[fregante]

Insert real href-links which the browser understands and applies the typical options you'd expect on. So you're able to e.g. right-click and open links in a new tab/window or middle-click the links, etc.

😍

Prefetch all links in the background. This is actually the key which enables all those exciting improvements.

Is this required for the feature to work? Are these prefetches actually reused by GitHub's pjax?

[stefanbuck]

Yes, this is needed for the real href-links and also reused by Github's pjax also know as turbo links.

[fregante]

I just tried the beta on this file: https://github.com/OctoLinker/OctoLinker/blob/master/packages/core/app.js

These are the requests: https://user-images.githubusercontent.com/1402241/57143759-30d09500-6df2-11e9-9328-755663eff22d.png

I don't see any paths that can be used by GitHub, specifically https://github.com/OctoLinker/OctoLinker/blob/62e1b2c902a634bc10f30fc04172a5318281265d/packages/core/octo-linker.js (the only successful import on the page). In fact clicking the module's link takes a few seconds to load.

Maybe I misunderstood what you mean by prefetch.

[leomoty]

@bfred-it if I understand correctly this is the call that prefetches everything:

https://api.github.com/repos/OctoLinker/OctoLinker/git/trees/62e1b2c902a634bc10f30fc04172a5318281265d?recursive=1

[leomoty]

Also, it gets cached:

Which is a nice bonus.

[fregante]

if I understand correctly this is the call that prefetches everything:

That's an API call; GitHub does not use the API

---

I think that @stefanbuck means that the modules are fetched and resolved on his server, not that the actual pages are pre-fetched in the browser. That's the source of the misunderstanding 😅

Therefore the URLs are used by pjax, not the prefetched pages. 👍

[stefanbuck]

First, thanks for the heads up @bfred-it, really appreciated 👍Also @leomoty for jumping in here.

No worries, we don't hammer the GitHub with requests. As you both already found out, OctoLinker performs two request, one against the GitHub Tree API and another one against our server which does the linking magic for external dependencies.

Please let me know if you have any other questions or concerns.

[fregante]

Question, why are you performing the requests on now instead of background.js? Does that impact the support for private repos/modules/enterprise? (not that I use any of them)

[stefanbuck]

First of all, the OctoLinker API is not new and exist since a long time already and is used by the current version of OctoLinker too. By resolving dependencies on the server side, the browser extension doesn't need tones of permissions to read data from all kind of websites such as npmjs.com, getcomposer.org ... which was the primary reason for building the API. We also use the sever to do some high level analysis how OctoLinker is being used (which registry and packages are popular ...). We don't track any user or repository identifiers. If you serve a private repo which is using dependencies from a private npm registry, the browse extension will send the package name to the OctoLinker API, but this shouldn't be mission critical in my opinion. If you're using a public dependencies within your private repository OctoLinker should be able to resolve it. Another side effect of using a "centralised" API is that every user benefit from already resolved dependencies from other users which improves the overall resoling time a lot. We cache resolved dependencies on Redis to reduce network calls to third-party providers such as npmjs.com, getcomposer.org, rubygems.org and more. RedisGreen supports OctoLinker with four dedicated servers and high availability in four regions.

[stefanbuck]

I want to send a hearty thank you to all you who take part in the beta. The new version got release yesterday so please uninstall the beta and continue using the offical OctoLinker version.