chore: bump @gmod dependencies and generic-filehandle

[manzt]

Closes #807

Change List

• bump @gmod/* packages
• bump generic-filehandle
• add optimizeDeps.esbuildOptions.inject to inject Buffer polyfill globally for all dependencies.

Checklist

• Ensure the PR works with all demos on the online editor
• Unit tests added or updated
• Examples added or updated
• Documentation updated (e.g., added API functions)
• Screenshots for visual changes (e.g., new encoding support or UI change on Editor)

[manzt]

seem to be issue with bigwig files ..

[manzt]

Ok I updated the vite.config.js to inject the Buffer into the dependencies.. This isn't ideal. Really, upstream we should have @gmod/* have explicit imports for Buffer in the library code:

import { Buffer } from 'buffer';

instead of just relying on a global. This is easier for bundlers to resolve, and something that I implemented a while ago in generic-filehandle.

GMOD/generic-filehandle#102

[manzt]

@sehilyi it seems adding those import { Buffer } from "buffer" is welcomed from the @GMOD folks. I won't be able to make this PR for a bit FYI

[sehilyi]

Thanks for letting me know. I might not be able to find time this week but probably possible next week.

[sehilyi]

I assume this change was needed by some recent changes in BBI?

[manzt]

Not exactly. This function returns either a promise or null, and we push the results to dataPromises. Previously the return type was Promise<void> | null. The async makes it always return a Promise.

        async loadBBI(dataConfig: { url: string }) {
            if (dataConfig.url) {
                this.bwFile = new BigWig({
                    filehandle: new RemoteFile(dataConfig.url)
                });
                return this.bwFile.getHeader().then((h: BigWigHeader) => {
                    this.bwFileHeader = h;
                });
            } else {
                console.error('Please enter a "url" field to the data config');
                return null;
            }
        }

[sehilyi]

I see – Good to know that.

[sehilyi]

Thanks for this change -- tested locally with demo examples and works well

[sehilyi]

@manzt Now there is a conflict in yarn.lock. Should we regenerate the lock file?

[manzt]

yah we can just copy the lock file over from master or relock.

git checkout master -- yarn.lock

[manzt]

ok, I rebased the changes @sehilyi

[sehilyi]

Thanks! I will go ahead and merge this.