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

Nested namespace identifiers errors with namespace must have a "ModuleBlock" body #246

Closed
3 tasks done
kraenhansen opened this issue Feb 3, 2023 · 3 comments
Closed
3 tasks done

Comments

@kraenhansen
Copy link

kraenhansen commented Feb 3, 2023

Checklist

  • I can reproduce this issue when running this plugin on its own.
    Other plugins, such as node-resolve are known to cause issues.
  • I am running this plugin on .d.ts files generated by TypeScript.
    The plugin can consume .ts and even .js files (with allowJs: true), but this is known to cause issues.
  • This issue is not related to rolling up @types.
    The plugin ignores these by default, unless respectExternal is set. @types can contain hand-crafted code which is known to cause issues.

Code Snipped

declare namespace Foo.Bar {}

Error Message

Error: namespace must have a "ModuleBlock" body.

Details

I get this error when using the shorthand for nesting namespaces (separating identifiers with dots).

I believe this is a more general case of #160.

Looking at the AST for this, the body of the first ModuleDeclaration is indeed another ModuleDeclaration and not a ModuleBlock as expected by the plugin.

Patching the default value of relaxedModuleBlock to true seems to solve the problem, but what would the drawback of that be?

@kraenhansen
Copy link
Author

This too. How was it "completed", when was / is the fix released?

@Swatinem
Copy link
Owner

I mass-closed all the issues, as I transition the project into maintenance mode and won’t be working on any of it, see #277
However I wasn’t able to mass-close-and-comment mentioning that.

@kraenhansen
Copy link
Author

Sure - I get the feeling of not having the time to drive actively drive project.
I do however find it a bit misleading that you're close issues, especially as "completed"?
Why not keep them around for others to find and contribute fixes for, as you're stating you welcome

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

Successfully merging a pull request may close this issue.

2 participants