- 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!)
## Summary
Fixes two related null reference errors in the GCC dump view's TomSelect
dropdown handling that occur during user interactions.
## Root Cause Analysis
**COMPILER-EXPLORER-96P** (1067 occurrences):
- Error: `TypeError: undefined is not an object (evaluating
't.filename_suffix')`
- Location: `gccdump-view.ts:318` in `onPassSelect()`
- Trigger: User deletes a selection via TomSelect → `deleteSelection()`
→ `removeItem()` → `trigger('change')` → `onPassSelect()` called with
passId that no longer exists in `this.selectize.options`
**COMPILER-EXPLORER-E44** (34 occurrences):
- Error: `TypeError: Cannot read properties of undefined (reading '0')`
- Location: `gccdump-view.ts:237` in dropdown open handler
- Trigger: `find()` returns undefined when searching for pass by
filename_suffix, but code uses non-null assertion `activeOption![0]`
Both errors occur due to timing issues when dropdown options are being
updated while user interactions are happening.
## Changes
1. **Added null check in `onPassSelect()`**: Safely handle case where
`this.selectize.options[passId]` returns undefined
2. **Removed unsafe non-null assertion**: Replace `activeOption![0]`
with proper null check and early return
3. **Added CLAUDE.md guidance**: Include preference for modern
TypeScript features like optional chaining
## Impact
- Prevents crashes with 1100+ reported occurrences combined
- Maintains existing user experience - dropdowns continue to work
normally
- No behavioral changes for valid interactions
Fixes COMPILER-EXPLORER-96P
Fixes COMPILER-EXPLORER-E44
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- 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!
-->
Co-authored-by: Ofek Shilon <oshilon@speedata.io>
<!-- 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!
-->
Replace the deprecated `monaco.editor.ICodeEditor.deltaDecorations` with `monaco.editor.IEditorDecorationsCollection`
Seems that today the official way of colouring monaco editors is having
them `createDecorationsCollection`, keep the resulting
decorations-collection and call `set` on it with new decorations
whenever needed.
There are many possible design choices on where to put it, I opted to
put `editorDecorations` in `MonacoPane`, and have
`MonacoPane.createEditor` initialize it only in panes where decorations
are actually used.
Also some signatures changed which had a broad (but non-interesting)
impact.
Makes the Compiler Explorer app, and all the tooling ESM compatible.
Things that have been done:
1. The package.json has `type: module` now
2. All relative imports have a .js ending
3. All directory imports are now directory/index.js to comply with ESM
standards
4. Dependency node-graceful is now imported into tree, because the
package is broken under esm
5. Dependency p-queue has been bumped to 7.x with ESM support
6. Dependency profanities has been bumped to 3.x with ESM support
7. Webpack config is now both ESM and CommonJS compatible
8. Non-ESM compatible imports have been rewritten
9. ESLint configuration has been tweaked to not fail on .js imports
10. Mocha is now hacked together and ran with ts-node-esm
11. Webpack is now hacked together and ran with ts-node-esm
12. Webpack config is now ESM compatible, so that it can be used in the
dev server
13. Cypress code still runs commonjs, and has been excluded from the
tsconfig
14. All sinon mock tests have been commented out, because sinon module
mocks do not work with ESModules (because ESModules are immutable)
A lot of tests are now giving warnings/errors to stdout, yet still pass.
Docenizer codegenerator scripts have been updated, but I did not re-run
them, and instead just changed their code.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
While doing some cleaning, the typing of the GCC dump feature was found
incorrect. This change tries to fix most of it... But some details still need to
be fixed (FIXME notes left in the code).
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
The type which probably started as a real enum of possible post filtering
options now also includes options used for compilers' invocations.
The type was already split, but the naming was not reflecting this in the other
part of the code.
This changes tries to apply a simple renaming to the type only (corresponding
variables are left as 'filters').
While doing so, some typing error were discovered around the GccDump feature.
A fix for this will follow in a different PR.
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
