Dead end with package installs between MODX versions?

Summary

I can’t find a way to create is package in MODX 3 that will install in MODX 2.

I’ve been working for months on a new version of MyComponent that will run in both MODX 2 and MODX 3, and create packages that will install and run in both versions without any deprecation notices.

I should have checked this sooner, but as far as I can tell, if you build a package on MODX 3, it can’t be installed on MODX 2. The problem is that MODX 3 puts the namespaced class of the transport vehicle inside every vehicle. The class is xPDO\Transport\xPDOObjectVehicle. MODX 2 has never heard of that class so you just get this over and over when trying to install the package in MODX 2:

Could not load class: xPDO\Transport\xPDOObjectVehicle from transport.xpdo\transport\xpdoobjectvehicle. 

A package created in MODX 2 will install fine in either version.

I don’t see any way around this, but it seems unlikely to me that we’re expecting everyone to keep a MODX 2 install around in order to create packages that can be installed in both versions. Maybe I’m missing something.

I should add that I don’t think this is a MyComponent issue. I think it affects any package created in MODX 3.

I just have a dedicated MODX 2 install with GPM that I use for building all my packages that need to work on both 2.x and 3.x.

It may be possible to alter the transport build process to use the deprecated alias flags, but that would take a PR and someone interested in going through the process of making that work. Additionally, I’m not sure if there are more fundamental differences in the xPDO\Transport object between 2.x and 3.x other than the class names. 3.x was built to be able to easily upgrade/migrate from a 2.x package, but not the other way around.

It occurred to me that the 2.x transport package installation code could be modified to use the basename of the provided class. I think it would solve the problem with no ill effects. I doubt if there are any other issues, but I could be wrong.