fix: plugins in extends configuration not taking effect (#796)

[jdz321]

Description

Fixes the issue where plugins defined in extended configuration files (via extends option) were not being loaded and executed.

Problem

As reported in #796, when using the extends configuration, plugins defined in the inherited configuration file do not take effect. The issue occurs because:

1. Plugin loading happens in the initPlugins stage before extends configuration is merged
2. The extends configuration processing occurs in the resolveConfig stage via api.modifyConfig
3. This timing mismatch prevents plugins from the extended config from being registered

Solution

• Parse extends config in preset stage: Move extends configuration parsing to the preset stage where api.registerPresets() can be called
• Store parsed config in appData: Use api.service.appData.extendsConfig to share parsed configuration between preset and plugin stages

Changes

• Modified src/preset.ts to parse extends configuration and register presets
• Updated src/features/configPlugins/configPlugins.ts to use pre-parsed extends config

Testing

• Added integration test case config-extends-plugins to verify the fix
• Test covers both plugins and presets inheritance from extends configuration

Fixes

Closes #796

Breaking Changes

None - this is a backward-compatible fix that only affects extends configuration behavior.

[PeachScript]

It is recommend to use api.registerPresets and api.registerPlugins to apply extended presets/plugins, and also in the configPlugins.ts rather than preset.ts

[jdz321]

Thanks for reviewing this PR. There are 2 points here that I'm uncertain about.

1. Is there any difference between using api.registerPresets / api.registerPlugins and directly returning presets/plugins within the preset? I perused the relevant code of @umi/core and discovered that both approaches involve creating a new Plugin and then amending the presets/plugins arrays.
2. We can't register presets in configPlugins.ts 'cause when it comes to running configPlugins.ts, the stage is already initPlugins. Presets can only be registered during the initPresets stage.

[PeachScript]

Parse extended configs in this stage means we cannot modify extends config in api.modifyConfig plugin hook, it looks like we should chose one of "plugins/presets extends " and "modifyConfig extends", how do you think?

[jdz321]

Yeah, I realized this problem too. However, to register plugins/presets, it must be done during the initPresets stage.

On the other hand, I believe the extends option is not very practical. Firstly, it uses path strings, and there is a lack of intelligent prompting when writing them. and it's easy to screw up, especially when the file directory structure changes. Secondly, the time when the extends config is merged is unclear to users.

As an alternative, directly importing the base config in the child config and merging it by user can solve all the above problems. It's just that presets/plugins need to use absolute paths. ..Incidentally, presets/plugins can also be designed to be directly imported instead of using path strings.

Considering all this, maybe we should just close this PR and leave the extends option as it is, what do you think?