-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(core): update build #977
Conversation
The main thing remaining is to change Also also I'm wondering if should get rid of knip since it only supports Node 16+. Or try downgrading it assuming it used to support Node 14. I cut most of the dependencies knip marked as unused. There's also a bunch of exports ( |
I've been experimenting with using esm.sh. Because HiGlass is UMD and not ESM, esm.sh can't get find any of the exports from HiGlass that Gosling uses.
@manzt Do you think it would be worth updating HiGlass to give it a ESM build? I see that what happens now is that it creates a higlass.umd.js which gets transpiled using babel (with plugin transform classes). The only alternative I can think of is to use importmaps. Its less clean but would probably get the job done. Here's the HTML I've been playing with:
|
Excited to see progress on this! Will try to take closer look this weekend. But just wanted to chime in.
If gosling really just runs in the browser, I don't really see a motivation to support legacy versions of Node.js for development purposes. Node 14 and 16 are both EOL, meaning they are no longer being developed or will receive security fixes https://endoflife.date/nodejs). I'd look into using Node 20 and maybe consider just testing in that environment. Could reduce CI times.
Yeah, I think that would be nice downstream. HiGlass will need to keep UMD for some time, due to its plugin system and other projects that rely on using it through script tags (many more higlass developers). However, one thing I've been very interested in there is breaking up higlass into smaller packages that are pure ESM. We would then have |
Good idea, I'll try it out!
Agreed and I would expect this to be relevant to our previous discussion too. |
edit: using the esm.shI attempted with importmaps and the esm.sh CDN but without success. It seems that esm.sh doesn't have the pixi v6.x so it keeps using pixi v5.3.12. I noticed this because the error relates to not being able to import this es6-promise-polyfill package. Not sure why it can't import this package.
Here is the html:
skypack.devI also tried using another CDN called skypack.dev, without success, although with a different error.
This error is a bit surprising because
Next stepsI'm wondering what the best way to go about troubleshooting this. Perhaps there is something obvious I'm missing, or perhaps there's some deeper understanding of how these CDNs work that I'm missing. My hunch is that there's something wrong with the higlass or gosling build that is causing these difficulties? More to investigate. |
editor/html-template.ts
Outdated
"react": "https://esm.sh/react@${reactVersion}?bundle", | ||
"react-dom": "https://esm.sh/react-dom@${reactVersion}?bundle", | ||
"pixi.js": "https://esm.sh/pixi.js@${pixiVersion}?bundle", | ||
"higlass": "https://esm.sh/higlass@${higlassVersion}?bundle", | ||
"gosling.js": "https://esm.sh/gosling.js@${goslingVersion}?bundle" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With ?bundle
I'm actually not sure gosling.js has any imports to resolve. I would be curious about just using:
import { embed } from 'https://esm.sh/gosling.js?bundle';
below. The main issue I issue I see with this is that I'm not sure how to control the version of HiGlass so that it aligns with the css.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
esm.sh says
In bundle mode, all dependencies are bundled into a single JS file except the peer dependencies.
So actually I don't need to import Higlass! Just react, react-dom, and pixi.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually you're right that does work! I'm surprised though. I'll have to read more about this bundle option.
import { embed } from "https://esm.sh/[email protected]?bundle"
embed(document.getElementById('gosling-container'), {...}
Node 20 has the Web Crypto API built in (globalThis.crypto). But Node 18 doesn't. Because of this, using changing crypto with What are our options? I'm pretty sure that @manzt 's PR #976 would fix this since it includes a fallback for |
Ya, I'm in favor of just using 20. Especially since it better reflects the environment Gosling actually runs in. We just need to communicate the change/requirement to the gosling team. We could also look into adding an |
That makes sense to me. I'll add a note about testing using Node 20 to the contributing doc and will add a .nvmrc. We can make an announcement to the Gosling channel when this PR is finalized. |
Removed mention of |
editor/html-template.ts
Outdated
gosling.embed(document.getElementById('gosling-container'), ${spec}) | ||
<div id="gosling-container"></div> | ||
<script type="module"> | ||
import { embed } from 'https://esm.sh/gosling.js@${goslingVersion}?bundle'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only question I have here is whether the version of higlass and gosling.js will stay in sync over time. Unfortunately the names used in the styles are specific to the higlass version, so I don't know if there could be a case where higlass makes a patch (e.g., v1.11.8) but we have styles from 1.11.7 in our template and the two end up out of sync. I wonder if it's possible to do something like:
import { embed } from 'https://esm.sh/gosling.js@${goslingVersion}?bundle&deps=higlass@${higlassVersion}';
but I'm not sure if the deps
is handled when bundle
is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to use different react and react-dom versions as well that user wishes to use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question. Ideally you could bundle and override dependency versions, but I'm not sure for ESM.sh if that is current possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tested. Unfortunately, it seems to ignore the version of the dependencies. I tried using a lower version of HiGlass and I still got HiGlass v1.12.4: http://higlass.io/
in the console. What I'll try next is to use the pre-bundled peer dependencies in an import map.
import { embed } from 'https://esm.sh/[email protected]?bundle&deps=higlass@$1.11.7';
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't have any luck using unbundled gosling.js with bundled peer dependencies either using an importmap.
The problem seems to be that HiGlass has "pixi.js": "^5.0.3"
as a peer dependency. One of the pixi subpackages called @pixi/polyfill
relies on a package called es6-promise-polyfill
which doesn't have the export that @pixi/polyfill expects. Thus I get a The requested module '/v133/[email protected]/es2022/es6-promise-polyfill.mjs' does not provide an export named 'Polyfill'
error when trying to import HiGlass.
Looking at that version of es6-promise-pollyfill it does look like there is export called Polyfill but I don't think it gets converted in a way that is accessible in the ESM version that esm.sh generates.
How hard it would it be to upgrade the pixi version that HiGlass uses to v6?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a PR to HiGlass to upgrade Pixi #977
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome. Thanks for all your work on this Etowah, looking great. Just one thought about esm.sh, otherwise LGTM!
"module": "dist/gosling.es.js", | ||
"types": "dist/src/index.d.ts", | ||
"files": [ | ||
"dist" | ||
], | ||
"type": "module", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup! Making things work nice (like Vite) might require upgrading those deps.
Ah, one thing I forgot. We have branch protection rules that require "Test (14.x)" and "Test (16.x)" to pass to merge into |
// export * as d3Queue from 'd3-queue'; | ||
// export * as d3Request from 'd3-request'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intended? Could be removed if not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The exports ford3Queue
and d3Request
were commented out so I just removed them. Perhaps they're unused in the parts of HiGlass that Gosling uses?
@manzt @etowahadams Removed the "Test (14.x)" and "Test (16.x)" branch protection rules. I will add one for 20.x after this is merged. |
Released HiGlass v1.13 |
Amazing thanks @manzt! Will try it out tomorrow. |
The polyfill error is resolved! Now encountering a new error due to HiGlass not being ESM. // [OLD] This still uses [email protected] and we get the polyfill import error
import { embed } from 'https://esm.sh/[email protected]';
// [NEW] This uses [email protected]
// No more polyfill error (yay!). However, we get a new error
// higlass.mjs does not provide an export named 'HiGlassComponent
import { embed } from 'https://esm.sh/[email protected][email protected]' Why is this failing? higlass.js is a UMD module. Esm.sh converts this into a ES module which has a single export: // https://esm.sh/v133/[email protected]/es2022/higlass.mjs
export {oNe as default}; So in import { HiGlassComponent as ps } from "/v133/[email protected]/es2022/higlass.mjs";
// ERROR: higlass.mjs does not provide an export named 'HiGlassComponent Potential solutionsAdd feature to esm.shOne solution which would require adding a feature to esm.sh. Currently esm.sh allows you to specify named exports from CJS file: import { HiGlassComponent } from "https://esm.sh/[email protected]?cjs-exports=HiGlassComponent"; This gets turned into the following in export * from "/v133/[email protected]/X-dHMvSGlHbGFzc0NvbXBvbmVudA/es2022/higlass.mjs";
import __cjs_exports$ from "/v133/[email protected]/X-dHMvSGlHbGFzc0NvbXBvbmVudA/es2022/higlass.mjs";
export const { HiGlassComponent } = __cjs_exports$; However, you can’t combine this feature with the // This doesn't work :(
import { embed } from 'https://esm.sh/[email protected][email protected]?cjs-exports=HiGlassComponent' So we would have to submit a PR to esm.sh to add this feature. ESM build for HiglassOnce again we return to this. I’m ready to make this a priority if others are onboard with me doing so. Add back the UMD buildWe could also just bring back the UMD build as a short term fix to merge this PR. This is tempting. |
Just waiting on higlass/higlass#1171 and we should be good to go! |
This should be everything. Thanks for all the work on HiGlass Trevor! |
Fix #
Toward #
Change List
Checklist