refactor(migrations): migrate depTypes

[RahulGautamSingh]

Changes

• migrate depTypes using AbstractMigration

Context

• Migrate inline with same sort  #11459

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

It looks like some package rules changed order in the tests. Is this correct/expected?

[RahulGautamSingh]

It looks like some package rules changed order in the tests. Is this correct/expected?

Expected but not correct. There were 2 cases to handle:

1. depTypes option (handled here)
2. Options such as devDependencies, peerDependencies, and others were not handled because they caused problems with imports of other functions. I attempted to make it work by handling only major parts of their entire logic in the custom class, as I had done with other options that used migrateConfig or mergeChildConfig in their migration-logic, but it did not work in this case. As a result, these options are migrated the old-fashioned way and they are added to packageRules after all other options have been migrated.

[viceice]

can we somehow avoid the snapshot changes?

[rarkins]

If you say it's not correct then does that mean you plan to fix it?

[RahulGautamSingh]

can we somehow avoid the snapshot changes?

I can't think of any way to Using PackageRule and PackageRuleInputConfig inpace of any

[RahulGautamSingh]

If you say it's not correct then does that mean you plan to fix it?

Yes, I want to and tried some approaches but none worked.
I am going to look into the issue which causes the imports to fail my guess is a race-condition so far.
We can convert it to draft and merge when the issue is fixed or that can be done in a future PR.

I have pushed new changes which are a way of handling it.

[rarkins]

Can these migrations be combined into a single one, or best to keep separate? They seem quite similar

[RahulGautamSingh]

Can these migrations be combined into a single one, or best to keep separate? They seem quite similar

I tried doing so but failed. The reason was that I tried to migrate them in the same-class as depTypes by adding an extra for-loop. It didn't work cause they didn't get migrated when depTypes option wasn't present in config.

So I had two ideas in mind:

1. Add that extra for-loop in the migration-class of an option which is always present (kinda hacky)
2. Have separate classes for them (not happy, cause redundant)
   I went with the second option.

IMO Best to keep separate. Even though they are related we treat them each as different options in config.

[renovate-release]

🎉 This PR is included in version 32.121.0 🎉

The release is available on:

• GitHub release
• 32.121.0

Your semantic-release bot 📦🚀