Skip to content

BridgeJS: Macro extension to define namespace #405

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

BridgeJS: Macro extension to define namespace #405

wants to merge 5 commits into from
+927 −15

Conversation

krodak
Copy link

@krodak krodak commented Aug 14, 2025

Introduction

This PR adds namespace-based convention support to the BridgeJS @JS macro, which enables creating TypeScript namespaces that are accessible globally in JavaScript, while maintaining direct export access.

Reasoning

Change allows up to align better with existing code conventions, but we believe it could be useful for others as well, without breaking any existing functionality

Feature example

  1. New @JS("namespace") macro
// New macro syntax with namespace parameter
@JS("__Swift.Foundation.UUID.create") func createUUID() -> String {
    UUID().uuidString
}

Example Swift code:

@JS("__Swift.Foundation.UUID.create") func createUUID() -> String {
    UUID().uuidString
}

@JS("__Swift.Foundation.UUID.validate") func validateUUID(_ uuid: String) -> Bool {
    UUID(uuidString: uuid) != nil
}

Generated TypeScript:

export {};

declare global {
    namespace __Swift {
        namespace Foundation {
            namespace UUID {
                function create(): string;
                function validate(uuid: string): boolean;
            }
        }
    }
}

export type Exports = {
    create(): string;
    validate(uuid: string): boolean;
}

Testing

Included new tests within Namespaces.swift

kateinoigakukun
kateinoigakukun reviewed Aug 14, 2025
View reviewed changes
Copy link
Member

@kateinoigakukun kateinoigakukun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, much appreciated!

I have a couple of questions:

  1. For something like:

    @JS("__Swift.Foundation")
class UUID {
    @JS("__Swift.Foundation")
    func uuidString() -> String {
        Foundation.UUID().uuidString
    }
}

    Do we actually need the namespace attribute on uuidString here? It seems that namespace on method decl is currently ignored. For such cases where namespace has no effect, it might be less confusing to emit an error or warning. In other words, how about restricting namespace parameter only for top-level declarations?

  2. About the public macro JS(_ namespace: String) interface:
    To keep it simple but extensible, how about changing it to public macro JS(namespace: String? = nil)?. Using a labeled parameter leaves room for adding more String parameters in the future. Also since macros can have default arguments, we probably don't need to have a dedicated overload. This would allow us to document both @JS and @JS(namespace:) together in a single DocC page.

@krodak krodak force-pushed the feat/macro-namespace branch from 7a2de9f to fff2554 Compare August 14, 2025 16:50
@krodak krodak force-pushed the feat/macro-namespace branch from fff2554 to 43a88d4 Compare August 14, 2025 16:57
@krodak
Copy link
Author

krodak commented Aug 14, 2025

@kateinoigakukun sounds good, thanks for valuable feedback 🙇🏼‍♂️

  • added warnings for non-top-level namespaces on functions and init
    • aligned examples and tests to reflect that
  • merged macros; was considering this, but wanted to avoid changing existing one, if you are fine with that, I think it's nicer this way 👌🏻
  • added example to existing docc documentation now that you mentioned this 🙏🏻
  • fixed swiftformat issues, added to pre-commit hooks, so hopefully won't break CI again
  • cleaned up commits a bit to prefix with BridgeJS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kateinoigakukun kateinoigakukun kateinoigakukun left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@krodak @kateinoigakukun