Add Linear.app adapter

[mtarnovan]

Adds a simple, DOM based Linear adapter.

The selectors are fragile (because Linear minimizes their CSS so we can't use their CSS classes) and will require updating if Linear adds more languages.

I had a few issues locally:

1. after running any tasks that create dist/ the path is picked up by yarn test which produces a lot of confusing test failures
2. (this is only an issue if one doesn't want to install Rosetta) the build system uses some notifiers that come with pre-built x86 executables for terminal-notifier. Those will crash on arm64 (Apple M1). Since terminal-notifier seems unmaintained, as a (very) dirty work-around one can compile terminal-notifier to get an arm64 executable (for example via brew) and use that binary instead:

   brew install terminal-notifier
   ln -sf `which terminal-notifier` node_modules/node-notifier/node_modules/node-notifier/vendor/mac.noindex/terminal-notifier.app/Contents/MacOS/terminal-notifier
   ln -sf `which terminal-notifier` node_modules/webpack-build-notifier/node_modules/node-notifier/vendor/mac.noindex/terminal-notifier.app/Contents/MacOS/terminal-notifier

   In lieu of a better fix, maybe we should add this to the README?

[mtarnovan]

Note that we could also use Linear's SDK to fetch ticket info, but I gave it a try and it felt slow, so I think it's worth the tradeoff of using selectors even if might need updating from time to time.

[mtarnovan]

Hey @klappradla,

Thanks for taking the time to review.

I've never heard of the tracker software

We switched from JIRA to Linear and so far we like it (although it is missing some more advanced features)

very fragile and likely to break on any updates

Understood. I can work on an alternative implementation using the official SDK then, it should be more reliable (albeit slower...).

Best, Mihai

[klappradla]

Hey @mtarnovan 👋

I thought about this PR again over the holiday. It would indeed be great if TicketyTick would support a more diverse set of trackers, even tools which bitcrowd isn't using internally. If you and your team are actively using the tool, we can be sure that breaking changes on the Linear.app side are detected quite fast.

So my suggestion would be: do a quick spike on a) trying to get the ticket's description field somehow and b) base the fetching on the API rather than the DOM. If both don't work out, I'd also be fine with merging the current approach from this PR.

Another note on fetching via the API: take a look at the notion.so and Jira adapters: it can make sense to use the internal API the SPAs are using, rather than a public API the tools offer. When building the notion.so adapter, I just opened the network tab in the developer tools to see what request the app does. As the client is already authenticated, we can just do the same requests in the extension 🤷

[mtarnovan]

Hey Max 👋

I thought about this PR again over the holiday. It would indeed be great if TicketyTick would support a more diverse set of trackers, even tools which bitcrowd isn't using internally. If you and your team are actively using the tool, we can be sure that breaking changes on the Linear.app side are detected quite fast.

We are probably going to stick with Linear for the foreseeable future, so yes, we can be the canary in the coal mine :-) I actually replaced the release extension with a dev build from this PR and have been using that at work in the last few days (we don't use the description field in commits anyway since it feels redundant)

So my suggestion would be: do a quick spike on a) trying to get the ticket's description field somehow and b) base the fetching on the API rather than the DOM. If both don't work out, I'd also be fine with merging the current approach from this PR.

Happy to give that a try when time permits.

Another note on fetching via the API: take a look at the notion.so and Jira adapters: it can make sense to use the internal API the SPAs are using, rather than a public API the tools offer. When building the notion.so adapter, I just opened the network tab in the developer tools to see what request the app does. As the client is already authenticated, we can just do the same requests in the extension 🤷

From my research Linear uses the same GraphQL API internally and externally (they provide an SDK that wraps it). They provide a global function loadLinearClient that loads an already authenticated client. My first implementation was using that, but it felt slow so I threw it out (as I mentioned above for us the description field is not at all important, since Linear has a Github integration that already takes care of that for us by adding the description to the PR automatically; so I prefered keeping the code fast and simple by not accessing any APIs)

I'll try what you're suggesting, but I'm pretty sure it will not work: their internal APIs are authenticated with Oauth bearer tokens, not with session cookies (like I assume notion.so does).

To summarize:

• the Linear adapter will probably have the limitation of not working on "index" views (sprint, board, roadmaps etc) since the markup makes it very difficult to reliably iterate over individual tickets from those pages; for us this is not important at all, but ofc I can't speak for other users of tickety-tick
• I'll work on your suggestions to integrate the API and get the description field too

Thanks again, Mihai

[mtarnovan]

@klappradla nice!

Please ping me when you release this to the extension stores so I can replace the locally build extension. I'll keep an eye on breakages and will try to fix them asap.