require('image!name') assets should use virtual/Image Set name instead of filesystem file names

[ccheever]

If you make an Image Set underImages.xcassets, the typical way to refer to those images is by the name of the Image Set. The Contents.json manifest can specify different images for different screen scales, which can be arbitrary file names.

It seems like the packager uses the filesystem names of the actual files instead of the Image Set name.

I think this is not great because its inconsistent with what I think most people would expect, and more importantly can break down if, for example, Contents.json specifies different file name roots for the @2x and @3x screen scales.

Two suggestions for ways to make this better:
(a) Make require(image!<name>) have <name> refer to the name of the Image Set rather than actual file names. I think this is probably the simplest and most straightforward but I may be overlooking things (stuff wrt. to Android or other workflows, etc.) that make this not a good choice.

or

(b) Require and enforce that file names and Image Set names be consistent so there's no confusion. The current state of things can lead to head scratching error messages about restarting the packager when the real problem is that the reference to the image is by Image Set name rather than filesystem file name. This seems pretty reasonable to me.

[amasad]

Thanks for the suggestions.

For context, what we have now is incomplete and is just a stepping stone. Our goal is to abstract asset management away completely from the platforms. That way you can put assets where you please regardless of the platform, and you can share assets across platforms. Furthermore we can see a world where you want to update the assets over the internet.

Not sure what could be dome in the near term to solve your issue cc @vjeux @nicklockwood

[nicklockwood]

For now, it's probably best just to either not use use xcassets, or manually ensure that the xcassets names match the files.

[ccheever]

@amasad @nicklockwood thanks. If I have lots of free time, I'll maybe make some sort of lint checker that could be integrated into the packager that would verify that everything matches up, but I probably won't bother. Closing this issue.