Align dependencies with Trino Web UI - #55
Conversation
koszti
changed the title
eb7f1c8 to
9d3a7a7
Compare
mosabua
left a comment
mosabua
left a comment
There was a problem hiding this comment.
Code changes all look good.
For the commit message please use the title
Align dependencies with the Trino web UI
And expand the commit body quite bit with a list of
- what trino version web UI we align with (483?)
- for each package we upgrade add something like "Upgrade mui deps from 7.3.2 to 9.3.1"
- add any other technical details worth knowing
Related question also .. should we pin dependencies more strictly or just continue relying on the lock file?
9d3a7a7 to
b424431
Compare
Upgrade MUI Material and icons from 7.3.2 to 9.3.1 Upgrade MUI X Data Grid from 8.14.0 to 9.11.0 Upgrade MUI X Tree View from 8.13.1 to 9.11.0 Update component markup and icon usage for compatibility with MUI 9.
Upgrade the React and React DOM peer requirements from 19.1.4 to 19.2.8 Upgrade React types from 19.1.13 to 19.2.18 Upgrade React DOM types from 19.1.9 to 19.2.4
Use the React, Emotion, MUI, MUI X, and Monaco instances supplied by an embedding application. Keep matching development dependencies for local builds and the standalone example. Keep Emotion at 11.14.0 and 11.14.1 and @monaco-editor/react at 4.7.0. Add monaco-editor 0.56.0 as an explicit shared dependency. Externalize peer dependencies and their submodule imports, publish only an ES module, and target ES2020 for the Vite configuration. Use the Monaco instance supplied through @monaco-editor/react in the library while configuring a slim Monaco instance for the standalone example. This reduces the JavaScript library output from approximately 24 MB across Monaco chunks and workers to 1.95 MB, or 332 KB compressed.
b424431 to
b256eaf
Compare
|
thanks, I split the change into three focused commits with expanded commit bodies:
Commit bodies show actual version bumps ahe dependency versions use Trino 484 (current snapshot) as the reference baseline. wdyt?
Even if we pin direct dependencies exactly, they and their transitive dependencies may still use version ranges. We therefore need the lockfile to reproduce the exact dependency tree across local, CI, and release builds. Peer dependencies (such as react, mui, monaco) should use ranges so host applications can provide compatible versions without dependency conflicts. does it make sense? |
koszti
changed the title
2 participants
Description
Align the dependencies with the trino web UI so the component can be embedded without bundling duplicate react, MUI, emotion or monaco runtimes.
Shared frontend libraries are now peer dependencies, the package uses MUI 9-compatible APIs (including the required react component markup updates). The library build externalizes these dependencies and produces a single ES module. This reduces the js build output from 24 MB across many monaco chunks and workers to 1.95 MB or 332 KB compressed.
The standalone example configures its own slim monaco instance while embedded consumers provide monaco through
@monaco-editor/react, allowing the query-ui to reuse an existing instance such as the one already configured by the trino web UI.Additional context and related issues
This PR partially addresses trinodb/trino#30827. The query-ui remains independently maintained and published as
@trinodb/trino-query-ui, allowing it to be embedded into other applications.