Better Type Errors#607
Conversation
# Conflicts: # docs/src/modules/2-bundle/4-conventions/4-types.md # lib/modules-lib/src/utilities.ts # src/bundles/curve/src/__tests__/curve.test.ts # src/bundles/curve/src/drawers.ts # src/bundles/sound/package.json
Bumps [fast-xml-parser](https://github.com/NaturalIntelligence/fast-xml-parser) from 5.3.6 to 5.4.1. - [Release notes](https://github.com/NaturalIntelligence/fast-xml-parser/releases) - [Changelog](https://github.com/NaturalIntelligence/fast-xml-parser/blob/master/CHANGELOG.md) - [Commits](NaturalIntelligence/fast-xml-parser@v5.3.6...v5.4.1) --- updated-dependencies: - dependency-name: fast-xml-parser dependency-version: 5.4.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
…-parser-5.4.1' into better-type-guards
|
I just noticed that without updating |
|
Certain ESLint rules that rely on Typescript linting also don't work on the CI but work locally. There's some weird shennenigans going on with the Typescript present in the CI environment and the in the local environment. |
|
I am confident that there's some weird discrepancy with the way Typescript is working on local machines and Github Actions, but I honestly can't tell what's wrong. But I've put in workarounds in the meantime |
# Conflicts: # yarn.lock
…ype-guards # Conflicts: # yarn.lock
I would not be surprised; the frontend has a discrepancy between TS diagnostics in IDE vs when running |
2 participants
Better Type Errors
Some general fixes to things that got missed out in previous PRs. Also re-exports
js-slang's rttc (runtime type checking) utilities and exposes them to modulesthrow-runtime-errorIntroduces a linting rule as well to highlight whenever an error being thrown doesn't inherit from the RuntimeSourceError type.
Devserver Changes
Since
js-slangnow allows us to customize what importers are being used, the devserver can now be used without the modules server.copy_gcandmark_sweeprefactorI modernized those two modules to bring them up to date with module contexts and other design patterns. They are sorely lacking in documentation however, so I don't actually know if anything is broken.
noImplicitAnynoImplicitAnyhas been enabled for all bundles and tabs and only left disabled for modules (likeunity_academy) that simply don't leave enough context clues or documentation for me to be able to create types for them. I've fixed type errors wherever I can, but a lot of bundles don't have tests so it's not always clear if any kind of functionality has been affected.