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.

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

Packaging Plugin #288

Merged
merged 1 commit into from
Mar 13, 2025
Merged

Packaging Plugin #288

merged 1 commit into from
Mar 13, 2025

Conversation

kateinoigakukun
Copy link
Member

@kateinoigakukun kateinoigakukun commented Mar 6, 2025 •
edited
Loading

Motivation

We are planning to have a code generation step for #290, and it will add some complexities to the packaging system.
However, the current de-facto packaging tool, carton has several issues.

carton originally served three main purposes: installing the Swift toolchain, building Web apps, and running tests. However, with the improvements in the Swift SDK, toolchain installation has been significantly enhanced, making it no longer an issue that our tools need to solve.

On the other hand, building and testing are heavily dependent on JavaScriptKit, so implementing them as a plugin within JavaScriptKit rather than maintaining carton separately is a more appropriate approach.

This change brings several benefits:

  1. Simplified version management: Previously, maintaining carton required keeping its version in sync with JavaScriptKit, which added maintenance overhead. By integrating this functionality directly into JavaScriptKit, this concern is eliminated.
  2. Reduced dependency burden for users: Users previously had to install both carton and JavaScriptKit, but with this change, only JavaScriptKit is needed.
  3. A more natural choice for library authors: Since carton functioned more like a devDependency, library authors were reluctant to include it as a dependency. By integrating the packaging functionality into JavaScriptKit, it becomes a more seamless and acceptable solution.

With this change, package management becomes more streamlined and consistent, improving both the developer experience and maintainability.

Additionally, this new packaging mechanism does not depend on SwiftPM's resource bundle, so #262 should be resolved too.

Example

With this change, any SwiftPM Package using JavaScriptKit can produce an ES Module with the following:

$ swift package --swift-sdk wasm32-unknown-wasi js
Building for debugging...
[0/2] Write swift-version--5A694DCA972CA112.txt
Build of product 'Basic' complete! (0.36s)
Packaging...
[1/7] .build/plugins/PackageToJS/outputs/Package/index.d.ts: building
[2/7] .build/plugins/PackageToJS/outputs/Package/index.js: building
[3/7] .build/plugins/PackageToJS/outputs/Package/instantiate.d.ts: building
[4/7] .build/plugins/PackageToJS/outputs/Package/instantiate.js: building
[5/7] .build/plugins/PackageToJS/outputs/Package/main.wasm: building
[6/7] .build/plugins/PackageToJS/outputs/Package/package.json: building
[7/7] .build/plugins/PackageToJS/outputs/Package/runtime.js: building
Packaging finished
$ tree .build/plugins/PackageToJS/outputs/Package/
.build/plugins/PackageToJS/outputs/Package/
├── index.d.ts
├── index.js
├── instantiate.d.ts
├── instantiate.js
├── main.wasm
├── package.json
└── runtime.js
$ cat index.html
<!DOCTYPE html>
<html>

<head>
  <title>Getting Started</title>
</head>

<body>
  <script type="module">
    import { init } from "./.build/plugins/PackageToJS/outputs/Package/index.js";
    await init(fetch("./.build/plugins/PackageToJS/outputs/Package/main.wasm"));
  </script>
</body>

</html>

@github-actions GitHub Actions
Copy link

github-actions bot commented Mar 6, 2025 •
edited
Loading

Time Change: +386ms (3%)

Total Time: 9,979ms

Test name Duration Change
Serialization/JavaScript function call through Wasm import with int 23ms +3ms (11%) ⚠️
Serialization/JavaScript function call from Swift 132ms +7ms (5%) 🔍
Serialization/Swift Int to JavaScript with assignment 358ms +28ms (7%) 🔍
Serialization/JavaScript Number to Swift Int 288ms +16ms (5%) 🔍
Serialization/Swift String to JavaScript with assignment 437ms +24ms (5%) 🔍
Serialization/JavaScript String to Swift String 3,841ms +229ms (5%) 🔍
View Unchanged
Test name Duration Change
Serialization/JavaScript function call through Wasm import 23ms -1ms
Serialization/Swift Int to JavaScript with call 1,000ms +40ms (4%)
Serialization/Swift String to JavaScript with call 1,067ms +33ms (3%)
Object heap/Increment and decrement RC 2,795ms +7ms (0%)
View Baselines
Test name Duration
Serialization/Call JavaScript function directly 3ms
Serialization/Assign JavaScript number directly 2ms
Serialization/Call with JavaScript number directly 3ms
Serialization/Write JavaScript string directly 4ms
Serialization/Call with JavaScript string directly 3ms

@kateinoigakukun kateinoigakukun mentioned this pull request Mar 10, 2025
Open
9 tasks
@kateinoigakukun kateinoigakukun force-pushed the yt/bundle-it branch 5 times, most recently from f8f82fb to 5284f28 Compare March 13, 2025 15:15
@kateinoigakukun
Add initial packager plugin
f841174 
This is very much a work in progress. It's just a proof of concept
at this point and just works for very simple examples.

The plugin invocation is as follows:

```
swift package --swift-sdk wasm32-unknown-wasi js
```
@kateinoigakukun kateinoigakukun marked this pull request as ready for review March 13, 2025 15:35
@kateinoigakukun kateinoigakukun merged commit 91ee909 into main Mar 13, 2025
7 checks passed
@kateinoigakukun kateinoigakukun deleted the yt/bundle-it branch March 13, 2025 15:35
@kateinoigakukun kateinoigakukun mentioned this pull request Mar 14, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@kateinoigakukun