Is your feature request related to a problem? Please describe.
Before PR #13366 the only way to use a single App Module for multiple binaries was to create an alias module and import everything from the real module into it. The mentioned PR improves things so that we can now map an App Module to a given binary. While all alias App Modules currently in core are mapped that way they cannot be simply removed as NVDA 2022.2 should preserve backward compatibility and some add-on may rely on one of these.
Describe the solution you'd like
These alias App Modules should be removed in the first compatibility breaking release after 2022.2. If any add-on imports from them an appropriate warning is logged so add-on authors have plenty of time to prepare. Note also that this is not backward incompatible i.e. if add-on imported from App Module for Spring Tool Suite and now it should import from the Eclipse module this does not break compatibility with earlier NVDA releases.
Most of these aliases are causing linter failures and in addition some of them cause Sphinx warnings when generating developer documentation
Describe alternatives you've considered
Leave these aliases alone.
Additional context
If it is decided we should remove alias modules this issue should be added into 2023.1 milestone.
Is your feature request related to a problem? Please describe.
Before PR #13366 the only way to use a single App Module for multiple binaries was to create an alias module and import everything from the real module into it. The mentioned PR improves things so that we can now map an App Module to a given binary. While all alias App Modules currently in core are mapped that way they cannot be simply removed as NVDA 2022.2 should preserve backward compatibility and some add-on may rely on one of these.
Describe the solution you'd like
These alias App Modules should be removed in the first compatibility breaking release after 2022.2. If any add-on imports from them an appropriate warning is logged so add-on authors have plenty of time to prepare. Note also that this is not backward incompatible i.e. if add-on imported from App Module for Spring Tool Suite and now it should import from the Eclipse module this does not break compatibility with earlier NVDA releases.
Most of these aliases are causing linter failures and in addition some of them cause Sphinx warnings when generating developer documentation
Describe alternatives you've considered
Leave these aliases alone.
Additional context
If it is decided we should remove alias modules this issue should be added into 2023.1 milestone.