Rename storyByModuleExport to resolveModuleExport

[tmeasday]

So it can return either, allowing generic uses of of={}

Issue:

What I did

Renamed the call, updated usages.

How to test

• I think we should add unit tests for docsContext. We should potentially wait to merge this.
• Basic usages should be tested by e2e tests I think.
• We don't currently automatically test external docs so we should check that still works.

[JReinhold]

This looks like a good first step. But componentOrStoryIdByModuleExport returns the ID, how would one go from that ID to the actual meta? For stories we have the storyById.

I think we want a helper like componentOrStoryIdByModuleExport, that returns the actual story/meta. At least for blocks, the ID is rather worthless and you almost always just take that ID and pass it to storyById, so it'd be nice to have that function directly.

On another note, I'm still confused as to when we use the meta term and when we call it component, but I guess you have that under control here.

[JReinhold]

After trying this out in the Description block, I'm seeing something unexpected that we should discuss.

the csfFile.meta returned when type is meta, is the "original, raw" Meta, and doesn't inherit anything from the project annotations. I guess I should have seen this coming, I don't know why I thought it would work. This means that parameters and others are vastly different between the returned meta and the primary story.

For Description, that makes the returned meta unusable, as it reads parameters.docs.extractComponentDescription as defined globally by renderers.
A workaround would be to read the primary story, but that wouldn't work in unattached mode.