-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
feat: support typescript linting and type checking #474
Conversation
698bc92
to
b94f3f8
Compare
the one major question I have here is whether we should use eslint@8, or use eslint@9 and internally pass the flag Note there is an official codemod for migrating the config so maybe apps can just run that: |
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.
Tested and working well in Route Manager and Maintenance (beta), both TS apps -- but getting dependency quirks in JS apps due to duplicate ESlint deps
Approved for testing in alpha to see if there are local dep resolution quirks going on with yalc
, and hopefully it will work on a normal NPM release 👍
# [10.8.0-alpha.1](v10.7.4...v10.8.0-alpha.1) (2024-10-22) ### Features * support typescript linting and type checking ([#474](#474)) ([b68f69a](b68f69a))
🎉 This PR is included in version 10.8.0-alpha.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
* feat: support typescript linting and type checking (#474) * feat: support typescript eslint * feat: run tsc --noEmit on typescript projects * chore: remove unused babel-eslint package * chore(release): cut 10.8.0-alpha.1 [skip release] # [10.8.0-alpha.1](v10.7.4...v10.8.0-alpha.1) (2024-10-22) ### Features * support typescript linting and type checking ([#474](#474)) ([b68f69a](b68f69a)) --------- Co-authored-by: @dhis2-bot <apps@dhis2.org>
This PR adds support to linting and type checking typescript projects.
Notes:
As part of this, I upgraded eslint to v8. This is not the latest, the latest v9 requires a new structure for eslint configs, and would mean that we'd have to pass a flag to use the old config in our projects. I plan to write an RFC for the next steps for the configs (proposing to use shared configs and using the CLI tool only as a helper for installing these configs) and I will look at upgrading eslint to v9 as part of that.
I added a check to run
tsc --noEmit
to do a type check on Typescript projects - this is an implicit test that runs wheneever it seems atsconfig.json
in the root of the project. I think that if a consumer is using TS then they should make sure it compiles, they're free to disable rules or change the config, but it should always compile.For this to work without a module resolution, we also need to bump this outdated version of TS in app-shell: fix: bump typescript version used in app shell app-platform#885
Right now, it shows the below warnning since hte eslint plugin was not updated to support the latest version of TS but that's not an issue
Testing
I tested this works with
route-manager-app
(TS),data-entry-beta
(JS),data-visualiser
(JS),maintenance-app-beta
(TS)Followups:
implements https://dhis2.atlassian.net/browse/LIBS-696