Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Packaging Plugin #288

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

Merged
kateinoigakukun merged 1 commit into main from yt/bundle-it
Mar 13, 2025
Merged

Packaging Plugin #288

kateinoigakukun merged 1 commit into main from yt/bundle-it
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>

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 

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
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.

2 participants

AltStyle によって変換されたページ (->オリジナル) /