Export common functionality

[dvmoritzschoefl]

We implemented a custom data fetcher for a track and therefore needed some functionality which was already in gosling, like functions to convert from absolute to relative genomic positions and vice versa. However these utility functions are not exported from the gosling library and therefore we had to rewrite/copy them, which is not optimal. It would be nice if all utility functions would be exported so they can be used from outside of gosling.

[sehilyi]

Hi @dvmoritzschoefl! Thanks for the suggestion, and we fully agree that it will be useful to expose utility functions for developers. Since there are a large number of utility functions in Gosling.js, and we are still figuring out which utility functions we want to make public, we would need to expose selected functions having clear use cases for developers.

In your case, it seems like functions in /utils/assembly.ts (code) are the ones that you would need, which are:

• getRelativeGenomicPosition
• computeChromSizes
• getChromInterval
• getChromTotalSize
• parseGenomicPosition

Can you confirm if these were the functions that you need to rewrite? Please also let me know if you have other utility functions in mind since that would be very helpful for us.

[sehilyi]

@manzt Would you have any general suggestions on this?

[dvmoritzschoefl]

Yes @sehilyi these were exactly the functions we needed. In addition I also think there was one called sanitizeChrName for removing the chr prefix from names. Basically our use case was that we had an API which delivered relative genomic positions and for gosling we needed relative ones (or vice versa).

[sehilyi]

@dvmoritzschoefl I made a PR for this (#997). Please let me know if it reflect on your use cases!

[dvmoritzschoefl]

@dvmoritzschoefl I made a PR for this (#997). Please let me know if it reflect on your use cases!

Yes that would cover everything we need. However most libraries would export it in a style like this

import { computeChromSizes, ... } from 'gosling.js/util'

This way auto import would still work (I think with the solution in the mentioned PR this would not be recognized by vscode)

[sehilyi]

This way auto import would still work (I think with the solution in the mentioned PR this would not be recognized by vscode)

Ah, good point. I followed how HiGlass supports utils functions (i.e., making utils an object that contains all utility functions). But, your suggestion seems to be closer to how we eventually want to support util functions when we make gosling.js a monorepo (#897):

import { computeChromSizes, ... } from '@gosling-lang/util';

Do you have any suggestions on how we can achieve your suggested syntax? i.e.,

import { computeChromSizes, ... } from 'gosling.js/util

(@manzt might have an idea!)

[manzt]

Ah just catching up here, I think I like the suggestion of having a separate package entrypoint for these utils in lieu of a separate package (i.e., gosling.js/utils). However, Gosling.js is currently bundled into a single JavaScript entrypoint when released to NPM.

Ideally we could set up the package.json to have:

{
  // ...
  "exports": {
    ".": "./dist/gosling.mjs",
    "./utils": "./dist/utils.mjs"
  }
}

However, this would require setting up out build to generate ./dist/utils.mjs. Maybe it's not that hard with all the changes from @etowahadams.