-
-
Notifications
You must be signed in to change notification settings - Fork 73
Comparing changes
Open a pull request
base repository: swiftwasm/JavaScriptKit
base: 0.50.1
head repository: swiftwasm/JavaScriptKit
compare: 0.50.2
- 6 commits
- 15 files changed
- 1 contributor
Commits on Apr 9, 2026
-
BridgeJS: Emit static methods and properties on namespaced class entries
The TypeScript `.d.ts` namespace-entry builder for `@JS(namespace:)` classes only emitted the constructor, silently dropping any `@JS static func` or `@JS static var` declared on the class. The equivalent path for non-namespaced classes (`renderExportedClass` → `dtsExportEntryPrinter`) iterates `klass.methods.filter(\.effects.isStatic)` and the static subset of `klass.properties`, so the output mismatched between the two paths. The generated JS class still carries the static members via `declarationPrefixKeyword: "static"` in `renderExportedClass`, and the namespace tree references it by symbol, so the JavaScript runtime works. TypeScript consumers, however, see an incomplete type and cannot call the static factory through `typeof MyNamespace.MyClass` without a hand-written augmentation. Mirror the non-namespaced path inside the `renderClassEntry` closure in `generateTypeScript` so namespaced classes emit their static methods and static properties alongside `new(...)`. Extended `Namespaces.swift` to exercise the codepath by adding a static factory and a static readonly property on the existing `__Swift.Foundation.Greeter` class. The Namespaces snapshot set captures the fixed output.
Configuration menu - View commit details
-
Copy full SHA for 6d2c070 - Browse repository at this point
Copy the full SHA 6d2c070View commit details -
BridgeJS: Consolidate namespaced and non-namespaced class DTS entry r…
…endering The `renderClassEntry` closure passed to `buildHierarchicalExportsType` manually rebuilt the same `ClassName: { new(...); staticMethod(); ... }` block that `renderExportedClass` already produces as its `dtsExportEntry` return value. The two paths had to be kept in sync by hand. Replace the inline closure with a direct call to `renderExportedClass` that discards the JS and DTS-type outputs and returns only the `dtsExportEntry` slice. This makes the class namespace entry for namespaced and non-namespaced classes identical by construction. Thread `throws` through `buildHierarchicalExportsType`, `populateTypeScriptExportLines`, and `generateTypeScript` to accommodate the fact that `renderExportedClass` is throwing. Hoist the `buildHierarchicalExportsType` call out of the `printer.indent` closure so the `try` expression is in a throwing context.Configuration menu - View commit details
-
Copy full SHA for 9a56b28 - Browse repository at this point
Copy the full SHA 9a56b28View commit details -
BridgeJS: Add e2e test for static method and property on namespaced c…
…lass Extends the existing `__Swift.Foundation.UUID` class (which already has an `@JS init` and an `@JS func`) with a static factory `fromValue(_:)` and a static readonly property `placeholder`, then asserts both are reachable via `exports.__Swift.Foundation.UUID.fromValue` and `exports.__Swift.Foundation.UUID.placeholder` in `prelude.mjs`. This is the e2e counterpart to the snapshot regression added in the previous commit — it proves the generated JavaScript actually routes calls to the correct static thunks at runtime, not just that the `.d.ts` types are well-formed.
Configuration menu - View commit details
-
Copy full SHA for d1ed185 - Browse repository at this point
Copy the full SHA d1ed185View commit details -
BridgeJS: Avoid double-rendering namespaced class DTS export entries
`renderExportedClass` was being called twice for every namespaced class: once in `collectLinkData` (to produce the JS body and instance interface) and once more inside the `renderClassEntry` closure (to produce the export-entry for `buildHierarchicalExportsType`), with the JS and instance-interface outputs discarded on the second call. Store the `dtsExportEntry` slice in `LinkData.namespacedClassDtsExportEntries` during the single `collectLinkData` pass, keyed by class name. The `renderClassEntry` closure is now a non-throwing dictionary lookup, so `buildHierarchicalExportsType`, `populateTypeScriptExportLines`, and `generateTypeScript` revert to non-throwing.
Configuration menu - View commit details
-
Copy full SHA for 575b2bf - Browse repository at this point
Copy the full SHA 575b2bfView commit details -
BridgeJS: Fix static property call expression for namespaced classes
Static properties on `@JS(namespace:)` classes used `property.callName()` to build the Swift call expression. That method consults `property.staticContext`, which is stored as `.className(abiName)` (e.g. `__Swift_Foundation_UUID`), and emits `\(abiName).\(propertyName)`. The ABI-mangled name is not a valid Swift identifier so the generated thunk failed to compile. Static methods were unaffected because `renderSingleExportedMethod` passes `klass.swiftCallName` directly. Fix `PropertyRenderingContext.callName(for:)` for the `.classStatic` case to bypass `property.callName()` and build the expression directly from `klass.swiftCallName`. This preserves the ABI symbol name (which still comes through `context.className` → `klass.abiName` → `property.getterAbiName(className:)`) while producing a valid Swift call expression in the thunk body. Also remove the now-unnecessary comment from `prelude.mjs` that described what the test was checking (the assertion itself is self-explanatory).
Configuration menu - View commit details
-
Copy full SHA for 57c1fd8 - Browse repository at this point
Copy the full SHA 57c1fd8View commit details -
Merge pull request #717 from PassiveLogic/kr/fix-class-static-method-ts
BridgeJS: Emit static methods and properties on namespaced class entries
Configuration menu - View commit details
-
Copy full SHA for 46182e2 - Browse repository at this point
Copy the full SHA 46182e2View commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 0.50.1...0.50.2