fix: relative name of exposed component

[serrg]

I would like to propose new optional --useFederatedAlias argument which takes precedence over automatically generated module name in declaration file (*.d.ts):

AS IS:
a) With federation.config.json like this:

{
  "name": "app",
  "exposes": {
    "./ComponentA": "./src/shared/ui/ComponentA",
    "./ComponentB": "./src/shared/ui/ComponentB",
  }
}

make-federated-types produces the following declarations (shared path is omitted):

declare module "app/ui/ComponentA" 
declare module "app/ui/ComponentB" 

b) With federation.config.json like this:

{
  "name": "app",
  "exposes": {
    "./ComponentA": "./src/shared/ui/ComponentA",
    "./ComponentB": "./src/test/ui/ComponentB",
  }
}

make-federated-types produces the following declarations (shared and test path are taken into module names):

declare module "app/shared/ui/ComponentA" 
declare module "app/test/ui/ComponentB" 

As you can see generated module name depends on source path (imho ts.createProgram somehow combines path) and you can not rely on this name during the imports on remote applications because you can have two possible import paths (and you don't know which one will be generated):

import ComponentA from "app/ui/ComponentA"; // with a) 
// or
import ComponentA from "app/shared/ui/ComponentA"; // with b)

TO BE:

make-federated-types --config ./path/to/my/config.json --useFederatedAlias

When you have federation.config.json like this:

{
  "name": "app",
  "exposes": {
    "./ComponentA": "./src/shared/ui/ComponentA",
    "./ComponentB": "./src/shared/ui/ComponentB",
  }
}

make-federated-types produces the following declarations:

declare module "app/ComponentA" 
declare module "app/ComponentB" 

When you have federation.config.json like this:

{
  "name": "app",
  "exposes": {
    "./myScope/ComponentA": "./src/shared/ui/ComponentA",
    "./myScope/ComponentB": "./src/test/ui/ComponentB",
  }
}

make-federated-types produces the following declarations:

declare module "app/myScope/ComponentA" 
declare module "app/myScope/ComponentB" 

[crutch12]

Nice PR!

But

You should use path.join instead of replace('./', '')

Just like in my closed PR:
https://github.com/pixability/federated-types/pull/12/files#diff-180b3d2af89416b99563fff8c37eb8ca1ef7591fc1ddd736b5dacf740ccd3760R80

const moduleDeclareName = path.join(federationConfig.name, exposeName).replace(/[\\/]/g, '/');

Also:
ts.createProgram + emit() may generate additional declarations

Example:

"exposes": {
  "./BellIcon": "./src/components/icons/BellIcon",
  "./MainAppContextProvider": "./src/components/main-app-context/MainAppContextProvider"
}

Generates 3 declarations, not 2:

declare module "icons/BellIcon" {
  ...
}
declare module "main-app-context/MainAppContext" {
  ...
}
declare module "main-app-context/MainAppContextProvider" {
  ...
}

So your compileKeys[index] won't match found moduleName

[serrg]

@crutch12 Nice catch! Thanks!
I have fixed PR with your solution and removed redundant --useFederatedAlias

[serrg]

@gthmb WDYT about this? :)

[crutch12]

@crutch12 Nice catch! Thanks!
I have fixed PR with your solution and removed redundant --useFederatedAlias

Nice!

I think it's right decision: useFederatedAlias should be default behavior.
But it's breaking change, so we have to release a new minor version :) (v0.2.0)

[serrg]

I think it's right decision: useFederatedAlias should be default behavior.

Exactly, I think the same that exposed name should take precedence over module name 👍

But it's breaking change

We can keep compatibility but after this we should introduce new argument for using exposed name as module name

[serrg]

@gthmb Do you still support this package?

[gthmb]

Hi! I lost access to this package when I changed jobs -_-. I have requested write access again to approve/merge PRs. Worst case , I can fork it and maintain a new fork, but I'd like to maintain this repo if possible.

[pix-pete]

Hi! I lost access to this package when I changed jobs -_-. I have requested write access again to approve/merge PRs. Worst case , I can fork it and maintain a new fork, but I'd like to maintain this repo if possible.

@gthmb Hey buddy! You should be good now ;-)

[gthmb]

This looks great! Thanks for sussing through the naming stuff here. I also agree that the exposed name should be the default behavior. I'll make a 0.2.0 release!