Typescript Migration #22: `client/modules/Preview`
Fixes #issue-number
Changes:
migrated client/modules/Preview to typescript
I have verified that this pull request:
- [X] has no linting errors (
npm run lint) - [X] has no test errors (
npm run test) - [ ] is from a uniquely-named feature branch and is up to date with the
developbranch. - [X] is descriptively named and links to an issue number, i.e.
Fixes #123 - [X] meets the standards outlined in the accessibility guidelines
Release Environments
This Environment is provided by Release, learn more! To see the status of the Environment click on Environment Status below.
:wrench:Environment Status : https://app.release.com/public/Processing%20Foundation/env-3ead4d2e19
Hi @NalinDalal, I've just run the CICD checks, and I think you have a few type-errors to resolve
Thanks for keeping a clean commit history! I see that all your commits have "no-verify" in the message, so I'm assuming you added the --no-verify flag to each?
Adding the --no-verify flag is only for when you have performed the initial update of the file extension from .js or .jsx to .ts or .tsx via git mv <file_relative_path>.js <file_relative_path>.ts
This is because we are expecting type errors when we perform this action, and we just want to commit the file extension update while conserving the file history
After this, please either run typechecks while you are working or allow the automated typecheck on commits to run by commit as usual without the --no-verify flag
yes, i noticed there are type-errors after I messaged on discord, will update soon
uhh, I made the changes, yes, thing is I think I took your tutorial literally, yes I've ran type-checks locally, now seems to pass, added the image for preview
Hi! I note there are types available for jshint and decomment from DefinitelyTyped:
Hi! I note there are types available for jshint and decomment from DefinitelyTyped:
@nbogie , Hi I am not quite sure I follow, can you explain?
are you asking me to include types for jshint and decomment?
Hi @NalinDalal ! Yes, including those types (as dev dependencies) would allow typescript to spot any type-errors in the codebase's use of those libraries, as well as give intellisense and (possibly) inline docs for those usages, too.
At the moment, your PR declares those library variables in a way which means they'll be given type any, essentially disabling type-checking for calls to those libraries and for the subsequent use of return values from those calls.
Just a suggestion!
Hi @NalinDalal ! Yes, including those types (as dev dependencies) would allow typescript to spot any type-errors in the codebase's use of those libraries, as well as give intellisense and (possibly) inline docs for those usages, too.
At the moment, your PR declares those library variables in a way which means they'll be given type
any, essentially disabling type-checking for calls to those libraries and for the subsequent use of return values from those calls.Just a suggestion!
thanks for heads up, types added.
@clairep94 @nbogie any updates on pr, do i need to do some changes, or is it rtm??