-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RD-1291 Introduced TS to backend #1575
Conversation
…fy-stage into RD-1291-backend-ts
@kubama can you split #d447df2 to smaller commits? |
I could, but I'm not sure it would be of much help. As I stated in the description, the core changes are limited to just a few json files. All the changes to the actual source files are just conversion to TS modules. There are no changes to a single file that could be split across different commits. |
Oh, quite big change. It'll take some time to review.
Having one commit containing both - rename and migration-related changes - won't help. AFAIR from what Grzegorz found is that GitHub works better if you do the rename in one commit and the changes inside the file in the other commit.
I see there's a problem with starting the backend:
Do we need any update in terms of installed packages on the server to execute Other questions before I jump into the review (possibly tomorrow):
|
Yes, I didn't expect that as I did just minor updates to the renamed files. In fact git respected renames for most of the files.
Nothing extra needs to be done. The issue here seems to be just the timeout - the backend now starts slightly longer, which is not unexpected. I increased the timeout and submitted new job (link in description updated).
No, db migrations and sequelize models (also used by migrations) are not changed. These are not directly imported, and the logic that handles them is part of cloudify-ui-common and used by composer as well - if we want these to be converted as well it will be best to first migrate composer backend to TS and then handle it as part of a separate ticket.
6 production source files and 3 test files are fully migrated.
Here are the steps in short:
|
There is one system test failure - looks like an issue with widget backend. I'll investigate. |
…fy-stage into RD-1291-backend-ts
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.
I did partial review (78/124 files) so far. Will continue later, probably tomorrow (due to the planned meetings). Added some comments.
Very hard to review files which are detected as deleted/added. It's not the time right now, but I'd suggest for the future to consider splitting such huge PR into smaller pieces. I suspect it must be possible to have it done within few PRs, one building on top of the other.
"settings": { | ||
"import/resolver": { | ||
"jest": { | ||
"jestConfigFile": "jest.config.js" | ||
} | ||
} | ||
}, |
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.
What was the reason behind removing it?
Did you have problems with resolving .ts
files? (if so, see my comment: https://github.com/cloudify-cosmo/cloudify-blueprint-composer/pull/921/files#r700138908)
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.
Yes, I couldn't make it working.
In the end there are two rules that check the same thing: node/no-missing-import
and import/no-unresolved
. There is no point in having both, so I decided to disable the second one (thus removing the setting).
import appConfig from '../../../conf/config.json'; | ||
import userConfig from '../../../conf/userConfig.json'; |
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.
If we bring back jest import resolver, we can avoid using such paths.
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.
Not really - the import resolver impacts eslint only. Here the issue was tsc not resolving the modules as they were originally specified
Thinking of it now I think it could be split into first introducing TS support without renaming any of the source files, and then gradually renaming the files and applying required changes (TS modules). Unfortunately I wasn't upfront aware of the scale of the changes that were required. I hope it's a lesson learned for composer backend work. |
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.
any new comments from me.
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.
Second part of the review. 104/124 files reviewed, so a bit closer to finish.
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.
OK, I'm done with the review. I have no more additional comments. I didn't manage to review all the files with the same attention to detail, but I believe that we have some time until the next release to detect any potential problems.
…fy-stage into RD-1291-backend-ts
Co-authored-by: Jakub Niezgoda <[email protected]>
…fy-stage into RD-1291-backend-ts
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.
Added two small comments.
Co-authored-by: Jakub Niezgoda <[email protected]>
…fy-stage into RD-1291-backend-ts
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.
I appreciate hard work on that migration 👍🏻
Could you summarize leftovers (migrations? DB models? any other?) and possibly add tickets for them? (labelled with UI stage typescript
)
Description
Although this PR is massive it's not as bad as it looks. All changes made to production and test code is just migration to TS modules, so the set of applied changes is pretty consistent across these files. Additionally there are some required changes around modules mocking in jest tests - I can elaborate about these on our weekly, as there are some gotchas.
Core changes are done in just a few files -
package.json
,tsconfig.json
and.eslintrc.json
.Unfortunately, a few files that were properly renamed appear as deleted/added after committing 🙁.
Screenshots / Videos
N/A
Checklist
Tests
https://jenkins.cloudify.co/view/UI/job/Stage-UI-System-Test/1185/
Documentation
N/A