Enable Biome's `organizeImports` with groups matching the original
ESLint `import/order` configuration:
1. **Node builtins** (`node:fs`, `path`, etc.)
2. *(blank line)*
3. **Third-party packages** (`express`, `@sentry/node`, etc.)
4. *(blank line)*
5. **Local/relative imports** (`../foo.js`, `./bar.js`, aliases)
This resolves the inconsistency where Biome wasn't enforcing import
grouping, meaning new files would lose the blank-line separation that
the old ESLint config enforced.
### Impact
- **354 files** updated out of 738 checked (~48%)
- **+188 / -240 lines** (net -52) — almost entirely single blank line
additions/removals between import groups
- No import reordering; purely group separator consistency
Fixes#7373🤖 Generated by LLM (Claude, via OpenClaw)
## Summary
This PR makes URL serialization logic available to Node.js contexts
(like Cypress tests) and replaces a hard-coded 4812-character base64 URL
in tests with programmatically generated state. This builds on the
shared utilities refactoring from #8246.
### Changes
#### 1. Extract URL Serialization to Shared Module
**Problem:** URL serialization code depended on GoldenLayout's
browser-only ConfigMinifier, preventing Cypress spec files from
importing it (they load in Node.js before running in browser).
**Solution:** Created `shared/url-serialization.ts` with a
Node-compatible ConfigMinifier reimplementation.
**Technical Details:**
- Reimplemented GoldenLayout's ConfigMinifier without browser
dependencies
- Moved serialization functions (`serialiseState`, `deserialiseState`,
`risonify`, `unrisonify`) to shared module
- Moved minification functions (`minifyConfig`, `unminifyConfig`) to
shared module
- Updated `static/url.ts` to use shared module instead of GoldenLayout
- Added comprehensive test coverage in `test/url-serialization.ts`
**Files:**
- **New:** `shared/url-serialization.ts` (~279 lines)
- **Modified:** `static/url.ts` (removed ~30 lines, eliminated
GoldenLayout dependency)
- **New:** `test/url-serialization.ts` (~96 lines)
#### 2. Replace Hard-coded Cypress URL with Programmatic State
**Before:** A hard-coded 4812-character base64 URL containing state for
all panes
```typescript
cy.visit('http://localhost:10240/#z:OYLghAFBqd5TB8IAsQGMD2ATApgUWwEsAXTAJwBoiQIAzIgG...');
```
**After:** Programmatically generated state using
`buildKnownGoodState()` function
```typescript
const state = buildKnownGoodState();
const hash = serialiseState(state);
cy.visit(`http://localhost:10240/#${hash}`, {...});
```
**Benefits:**
- Human-readable, maintainable test state
- Programmatic generation from `PANE_DATA_MAP` keys
- Layout optimized with 8 panes per row
- Produces identical compressed URL format
- Much easier to add/modify panes in the future
#### 3. PANE_DATA_MAP Consistency Improvements
Updated `PANE_DATA_MAP` to use component names exactly as registered
with GoldenLayout:
**Key renames:**
- `preprocessor` → `pp`
- `llvmir` → `ir`
- `pipeline` → `llvmOptPipelineView`
- `mir` → `rustmir`
- `hir` → `rusthir`
- `macro` → `rustmacroexp`
- `core` → `haskellCore`
- `stg` → `haskellStg`
- `cmm` → `haskellCmm`
- `dump` → `gccdump`
- `tree` → `gnatdebugtree`
- `debug` → `gnatdebug`
**Added panes:** `codeEditor`, `compiler`, `conformance`, `output` (were
missing from map)
**Re-enabled tests:**
- `yul` pane test (was commented out, now fixed)
- `clojuremacroexp` pane test (was commented out, now fixed)
- `cfg` pane test (had TODO, now removed)
**Why this matters:** The `buildKnownGoodState()` function uses
`Object.keys(PANE_DATA_MAP)` as the `componentName` property, so keys
must match the actual registered component names for GoldenLayout to
find them.
## Test Plan
- [x] All Cypress tests pass (confirmed by @mattgodbolt)
- [x] TypeScript compilation passes (`npm run ts-check`)
- [x] Linting passes (`npm run lint`)
- [x] URL serialization tests pass (3/3 tests)
- [x] Pre-commit hooks pass
- [x] Related vitest tests pass
## Dependencies
- Builds on #8246 (shared utilities refactoring - already merged)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Moves `static/assert.ts` and `static/rison.ts` to `shared/` directory to
make them available to both frontend and backend code without browser
dependencies. Updates all import paths across the codebase (~47 files).
## Motivation
This refactoring eliminates browser dependencies in these utilities,
allowing them to be imported by Node.js contexts (like Cypress test
files) without causing module load failures. This is a prerequisite for
upcoming Cypress test improvements.
## Changes
- Move `static/assert.ts` → `shared/assert.ts`
- Move `static/rison.ts` → `shared/rison.ts`
- Update `biome.json` to allow `hasOwnProperty` in `shared/` directory
- Update all imports across `static/`, `lib/`, and `test/` directories
(47 files changed)
## Benefits
- No functional changes, purely a code reorganization
- Makes these utilities accessible to both frontend and backend without
circular dependencies
- Enables future Cypress improvements that require these utilities in
Node.js context
- All tests pass ✓ (699 tests)
## Test Plan
- [x] TypeScript compilation passes
- [x] Linting passes
- [x] All unit tests pass (699 tests)
- [x] Pre-commit hooks pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
- latest biome, and fix its configuration
- fixes "static" content to be globally configured too (instead of
per-line)
- fixes issues:
- imports fixed up
- `Date.now()` vs `+new Date()`
- some unused things `_` prefixed
After discussion with the team, turned off the unused parameter warning.
- Removes `rootDirs` so all imports will be relative in the frontend
- Updates (and unifies) imports to be `../types/...` etc instead of
relying on "types" being in the rootDir for the frontend.
- Fixes one type that was being picked up from `lib` in the frontend.
- Adds a precommit hook to check in future
Paves the way to writing _unit_ tests for the frontend for the subset of
the frontend code we can import from `node` (which might be a lot of
it!)
Fixes#7792
Bootstrap styles `a:has([href])` as a link so the attribute had been
used in the past for things that aren't actually links, yet we want the
style for. It's better to just use `.link-primary` so it doesn't affect
the contents as discovered in #7792
This PR completes the migration from Bootstrap 4 to Bootstrap 5.3.5
following the plan outlined in
[docs/Bootstrap5Migration.md](https://github.com/compiler-explorer/compiler-explorer/blob/mg/bootstrap5/docs/Bootstrap5Migration.md).
## Migration Process
We followed a phased approach as documented in the migration plan:
1. **Phase 1: Dependency Updates and Basic Setup**
- Updated Bootstrap from 4.6.2 to 5.3.5
- Added @popperjs/core dependency (replacing Popper.js)
- Updated Tom Select theme from bootstrap4 to bootstrap5
2. **Phase 2: Global CSS Class Migration**
- Updated directional utility classes (ml/mr → ms/me)
- Updated floating utility classes (float-left/right → float-start/end)
- Updated text alignment classes (text-left/right → text-start/end)
3. **Phase 3: HTML Attribute Updates**
- Updated data attributes to use Bootstrap 5 prefixes (data-bs-toggle,
data-bs-target, etc.)
- Fixed tab navigation issues
4. **Phase 4: JavaScript API Compatibility Layer**
- Created bootstrap-utils.ts compatibility layer
- Updated component initialization for modals, dropdowns, popovers, etc.
5. **Phase 5: Component Migration**
- Updated and tested specific components (modals, dropdowns, toasts,
etc.)
- Fixed styling issues in cards and button groups
6. **Phase 6: Form System Updates**
- Updated form control classes to Bootstrap 5 standards
- Updated checkbox/radio markup patterns
- Simplified input groups
7. **Phase 7: Navbar Structure Updates**
- Updated navbar structure with container-fluid
- Fixed responsive behavior
8. **Phase 8: SCSS Variables and Theming**
- Added custom CSS fixes for navbar alignment
- Verified theme compatibility
9. **Phase 9: Accessibility Improvements**
- Updated sr-only to visually-hidden
- Added proper ARIA attributes
- Enhanced screen reader support
## Key Changes
- No more jQuery dependency in Bootstrap 5
- New prefix for data attributes (data-bs-*)
- Improved accessibility with ARIA attributes
- Updated positioning classes (start/end instead of left/right)
- Simplified input group structure
## Test Plan
1. **Navigation Testing**
- Verify all dropdown menus open and close properly
- Test mobile menu responsiveness
- Check tab navigation in settings dialog
2. **Component Testing**
- Verify all modals open and close correctly (settings, share,
load/save)
- Test tooltips and popovers
- Check form controls in different dialogs
3. **Layout Testing**
- Test responsiveness on different screen sizes
- Verify proper alignment of elements
- Check dark mode compatibility
4. **Specific Features to Test**
- Compiler selection and options
- Share dialog functionality
- Settings dialog
- Tree view (IDE mode)
- Font selection dropdown
5. **Browser Testing**
- Test in Chrome, Firefox, Safari
- Test in mobile browsers
## Note on Further Improvements
After this migration is stable, we could consider Phase 12: removing
jQuery dependency entirely, as Bootstrap 5 no longer requires it. This
would be a separate effort.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Does some winter cleaning on the site-template stuff :)
1. Migrated away from the custom conf format to plain old yaml
2. Made the images and image files match with the name from the yaml
file. (It's not a problem to have spaces in file paths, nor urls so I
don't see why we shouldn't)
3. Updated the relevant documentation
There is a small breakage in the api response for the meta field. It now
returns `{"screenshot_dimensions":{"width":1000,"height":800}}` which I
believe is a lot more useful than
`{"meta.screenshot_dimensions":"1000x800"}`
Besides, I don't believe this endpoint has any third-party consumers
that rely on the metadata since it's a rarely known feature anyways
This is the first PR in API consistency with more to come:
1. The source API urls have been properly defined with
`/source/:source/list` and `/source/:source/load/:language/:filename`
- These used to be two API endpoints mushed together into one `handle()`
function. They are now separate
- While it may appear from the tests that this is an API breakage,
there's currently no way to have the source API spit out responses for
stuff like `/source/moose/load/Grunkle`.
2. The frontend code calling the list api now has shared types
3. Code has been migrated to `/lib/handlers/api/source.ts`
- I've moved code here, because I would like to separate the stuff
that's under the API and the stuff that isn't (e.g., healthcheck)
- The source endpoint is currently not under /api, but I believe it
makes sense to move it.
4. GitHub is terrible at showing the diff, but the `browser.ts` file has
been removed, since it's never actually used. Our frontend only calls
`/source/builtin/...` and it never had any entries. Besides, the type
used on the frontend for the locally stored stuff is different...
<!-- THIS COMMENT IS INVISIBLE IN THE FINAL PR, BUT FEEL FREE TO REMOVE
IT
Thanks for taking the time to improve CE. We really appreciate it.
Before opening the PR, please make sure that the tests & linter pass
their checks,
by running `make check`.
In the best case scenario, you are also adding tests to back up your
changes,
but don't sweat it if you don't. We can discuss them at a later date.
Feel free to append your name to the CONTRIBUTORS.md file
Thanks again, we really appreciate this!
-->
This fixes an ordering issue with font scales. The issue would happen if
you changed the default font scale and then e.g. opened a tool window.
It would have the "default" size selected; but it wouldn't apply to the
editor window.
When each `Pane` (and others) create their own `PaneRenaming`, which
extends `EventEmitter.EventEmitter`, when one actor emits `renamePane`
no other actor can hear it.
This PR makes `PaneRenaming` stop using its own event emission, and
instead use the central `Hub` it now receives at its ctor.
All `Alert` modal windows reuse the same yesButton/noButton.
The callback are setup in the Alert ctor -
```
const yesNoModal = $('#yes-no');
yesNoModal.find('button.yes').on('click', () => {
this.yesHandler?.();
});
yesNoModal.find('button.no').on('click', () => {
this.noHandler?.();
});
}
```
On every yes/no click, *All* callbacks of *All* alert instances are
called.
So each `Alert` instance needs to cleanup its callbacks after usage, and
it tries to - via the weirdly named `toggleEventListener`.
`toggleEventListener` only did
```
element.off(eventName);
```
Some of the renaming problems were caused by persistance of [this
callback](00648a7e1c/static/widgets/pane-renaming.ts (L68-L72)).
Extending the cleanup to -
```
element.off(eventName);
this.yesHandler = null;
this.noHandler = null;
```
seems to solve it this particular problem - not even sure `element.off`
is even needed.
<!-- THIS COMMENT IS INVISIBLE IN THE FINAL PR, BUT FEEL FREE TO REMOVE
IT
Thanks for taking the time to improve CE. We really appreciate it.
Before opening the PR, please make sure that the tests & linter pass
their checks,
by running `make check`.
In the best case scenario, you are also adding tests to back up your
changes,
but don't sweat it if you don't. We can discuss them at a later date.
Feel free to append your name to the CONTRIBUTORS.md file
Thanks again, we really appreciate this!
-->
Hey friends, it's been a while since last time :)
There are quite a few conditions/cases where the library alert will pop
up, without anything meaningful inside of it. This is particularly the
case for Rust where you have the 100 crates on stable, but zero support
in beta/nightly. I figured informing the user in cases like this would
be nice to have.
This PR adds a rather simple alerting mechanism to alert the user of any
conditions that might not be as apparent (such as Rust crates only being
on stable)
Below is a small gif of how it works. I'm not sure this is the easiest
way to convey this information (especially considering the modal popup
overshadows the alert) so please share any other ideas. Maybe it's
better to have the content fill the modal instead?
Relevant issues: #3766#6250
This prepares for future work that will reuse the opt pipeline view
outside of the LLVM ecosystem by renaming related components to remove
the LLVM prefix.
The pass dumper keep its LLVM prefix, as it is assumed this part is
likely to be customised for each compiler ecosystem.
The historical component name has been preserved in the component list
as an alias to keep old links working.
