Movatterモバイル変換

[0]ホーム
URL:

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
kateinoigakukun merged 1 commit intomainfromyt/bundle-it
Mar 13, 2025
Merged

Packaging Plugin#288

kateinoigakukun merged 1 commit intomainfromyt/bundle-it
Mar 13, 2025

Conversation

@kateinoigakukun
Copy link
Member

@kateinoigakukunkateinoigakukun commentedMar 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 jsBuilding for debugging...[0/2] Write swift-version--5A694DCA972CA112.txtBuild 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: buildingPackaging 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
Copy link

github-actionsbot commentedMar 6, 2025•
edited
Loading

Time Change: +386ms (3%)

Total Time: 9,979ms

Test nameDurationChange
Serialization/JavaScript function call through Wasm import with int23ms+3ms (11%)⚠️
Serialization/JavaScript function call from Swift132ms+7ms (5%)🔍
Serialization/Swift Int to JavaScript with assignment358ms+28ms (7%)🔍
Serialization/JavaScript Number to Swift Int288ms+16ms (5%)🔍
Serialization/Swift String to JavaScript with assignment437ms+24ms (5%)🔍
Serialization/JavaScript String to Swift String3,841ms+229ms (5%)🔍
View Unchanged
Test nameDurationChange
Serialization/JavaScript function call through Wasm import23ms-1ms
Serialization/Swift Int to JavaScript with call1,000ms+40ms (4%)
Serialization/Swift String to JavaScript with call1,067ms+33ms (3%)
Object heap/Increment and decrement RC2,795ms+7ms (0%)
View Baselines
Test nameDuration
Serialization/Call JavaScript function directly3ms
Serialization/Assign JavaScript number directly2ms
Serialization/Call with JavaScript number directly3ms
Serialization/Write JavaScript string directly4ms
Serialization/Call with JavaScript string directly3ms

This is very much a work in progress. It's just a proof of conceptat this point and just works for very simple examples.The plugin invocation is as follows:```swift package --swift-sdk wasm32-unknown-wasi js```
@kateinoigakukunkateinoigakukun marked this pull request as ready for reviewMarch 13, 2025 15:35
@kateinoigakukunkateinoigakukun merged commit91ee909 intomainMar 13, 2025
7 checks passed
@kateinoigakukunkateinoigakukun deleted the yt/bundle-it branchMarch 13, 2025 15:35
Sign up for freeto 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

@kateinoigakukun
[8]ページ先頭
©2009-2025 Movatter.jp