Handling renamed default exports and declaration resolution in module references

[nnaydenow]

class Test {
    test = true;
}

export default Test;

import Test1 from "./a.js"; // Not "Test" to avoid name conflict. It must be "Test1" for this reason.

// This class, defined in a separate package, extends the base class with additional features.
class Test extends Test1 {}

export default Test;

The reference type does not indicate whether this is a renamed default export.

My question is about how this should work and what the correct usage is.

Should my reference be:

{
  "name": "default",
  "module": "a.js"
}

And if I need the declaration, should I look it up in the exports of "a.js" to find the actual declaration name before working with it?

If so, there’s a bug in the auto-merger, because it doesn’t merge parent and child declarations.

[break-stuff]

Are you able to export both:

class Test {
    test = true;
}

export default Test;

Or provide an alias for your exported class?

import { Test as Test1 } form "./a.js";

[nnaydenow]

I've prepared an example where you can see what I've tried: https://github.com/nnaydenow/cem-references/

Even the built-in hierarchy resolver doesn’t seem to handle this case. Is that expected, or is it only intended for simpler scenarios?

As I mentioned, we have components with the same name in two different packages — for example, package-a/TextArea.js and package-b/TextArea.js. The one in package-b extends and enhances the one from package-a.

I'm building documentation that aims to display all properties in a fully resolved way — including properties and other members from all classes in the hierarchy, even if they’re defined across different packages.

[break-stuff]

I think you might be able to use my inheritance plugin. It provides an alias map feature where you can specify the parent.