Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ctix fails when source file contains two exports to the same wildcard module declaration #62

Closed
insidewhy opened this issue Nov 9, 2022 · 4 comments

Comments

@insidewhy
Copy link
Contributor

insidewhy commented Nov 9, 2022

Take this code which is typical for a project built with webpack:

/// <reference path="./DeclareTtfModule.d.ts" />
import RobotoBold from "./fonts/Roboto-Bold.ttf";
import Roboto from "./fonts/Roboto-Regular.ttf";

export { RobotoBold, Roboto };

and where DeclareTtfModule.d.ts looks like:

declare module "*.ttf";

Trying to compile a project like this exits with a non-zero status code and with the same error reported identically four times against the final line:

> detect same name of export statement: ""*.ttf""

Changing the final line so it only exports a single symbol works fine:

/// <reference path="./DeclareTtfModule.d.ts" />
import RobotoBold from "./fonts/Roboto-Bold.ttf";
import Roboto from "./fonts/Roboto-Regular.ttf";

export { RobotoBold }

Fixed this issue in #64

insidewhy added a commit to sol-x/ctix that referenced this issue Nov 9, 2022
@insidewhy insidewhy changed the title ctix fails when source file contains two exports of the same extension when it is not .ts or .tsx ctix fails when source file contains two exports with the same wildcard type declaration Nov 9, 2022
insidewhy added a commit to sol-x/ctix that referenced this issue Nov 10, 2022
insidewhy added a commit to sol-x/ctix that referenced this issue Nov 10, 2022
insidewhy added a commit to sol-x/ctix that referenced this issue Nov 10, 2022
insidewhy added a commit to sol-x/ctix that referenced this issue Nov 10, 2022
@insidewhy insidewhy changed the title ctix fails when source file contains two exports with the same wildcard type declaration ctix fails when source file contains two exports with the same wildcard module declaration Nov 10, 2022
@insidewhy insidewhy changed the title ctix fails when source file contains two exports with the same wildcard module declaration ctix fails when source file contains two exports to the same wildcard module declaration Nov 10, 2022
insidewhy added a commit to sol-x/ctix that referenced this issue Nov 10, 2022
@imjuni imjuni closed this as completed in 186c24c Nov 11, 2022
@imjuni
Copy link
Owner

imjuni commented Nov 12, 2022

@insidewhy Hi,

Thank you for your contribution!

I've improved your contribution a little bit. I think use compiler api that more accuracy for each situation.

as-is -> to-be

In this case, TypeScript Compiler API return module declaration node instance. And module declaration node return glob pattern applied name.

eg. Friend > *.ttf

So I module declaration node change that return export declaration key. It make information like that,

{
  identifier: 'Friend',
  isIsolatedModules: false,
  moduleDeclaration: "'*.ttf'",
},

This improvement can remove the need to change the duplicate detection code. If you agree with this change, I will release the next version in this state.

@imjuni imjuni reopened this Nov 12, 2022
@insidewhy
Copy link
Contributor Author

This improvement can remove the need to change the duplicate detection code. If you agree with this change, I will release the next version in this state.

I wanted to do that also, couldn't find a way to do it without changing a lot of other code. From getExported to getExport...

@imjuni
Copy link
Owner

imjuni commented Nov 12, 2022

@insidewhy Thank you for your kindness.

I completly agree changing only on validation logic. But I think that exportInfo result less about for validation. But I think the 'exportInfo' function doesn't return information to do the right validation.

Thank you for your feedback! I will release this version soon!

@imjuni imjuni closed this as completed Nov 12, 2022
@insidewhy
Copy link
Contributor Author

Thanks for releasing the fix so quickly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants