Description
When detecting modules prior to 8.1.0 the folder name was used as the source of truth for the module id, with the changes in TIMOB-20379 we started to use the id field in the manifest as the source of truth.
I guess it could be argued that this is down to to.imagcache having an error and our behaviour now is more correct, it *_is_* a change of behaviour from previous SDKs.
Steps to reproduce
1. Clone
https://github.com/ewanharris/test-module-detection
2. Build the project with
appc run -p ios --build-only
3. Change the SDK to and 8.2.0 or 8.1.0 SDK
4. Repeat step 2
Actual
When using 8.2.0/8.1.0 the build fails as it cant find the to.imagecache module
Expected
Unsure, it could argued we're being more correct now but this has introduced a regression through a change in behaviour Build should find the to.imagecache module
So the module in question actually has a fixed moduleid as of a year ago. I'm not certain how common this is for 3rd party modules, but I think we should consider opening a separate ticket for the module build process to check inconsistencies like this one (and others). Possible checks: - inconsistent module id versus folder name - inconsistent version versus folder version - mis-matching versions across different platforms? (try to encourage keeping them in sync?) It was also raised that we should consider supporting package.json to replace the manifest file.
I wonder if this is happening due to the module a legacy install with a different module id? Say you have a module with id "foo.bar", it will create the directory "foo.bar". Now we update the id to "Foo.Bar". Thanks to Windows and macOS (by default) having case-insensitive filesystems, it detects the directory as already existing and just dumps the module in a version directory. Node doesn't test case sensitivity. For example,
fs.mkdirSync('./foo'); console.log(fs.existsSync('./FOO')); // true. I don't know where Studio is getting their module id from in the tiapp editor, but I suspect it's fromappc ti module -o jsonand this command will return the modules grouped by the directory name. At the end of the day, the module manifest should be the source of truth. If you have a module FOO@1.0.0 and foo@2.0.0, on disk they can both live in a "FOO" or "foo" directory, but the detection code should treat them as 2 different modules.