Revert "Use `--static-swift-stdlib` for easier distribution on Linux (#343)"
This reverts commit 78d023587c.
As reported previously:
> after adding --static-swift-stdlib, carton init and other commands started hanging.
> It seems something wrong in Foundation or global executor. The min repro for the hang is here
> https://gist.github.com/kateinoigakukun/a3ee55fa2480a46959211c53de862131
* Add WebDriverClient for headless testing
* Launch new session with headless arg by default
* Add --headless option in carton test
* Improve logging message
* Apply formatter for WebDriverClient module
* Support MS Edge
* Add headless testing test
* Explicitly depend on NIOFoundationCompat
* Avoid public actor field as a 5.5 compiler crash workaround
* Add --headless description in README.md
* Update Sources/CartonCLI/Commands/Test.swift
Co-authored-by: Max Desiatov <max@desiatov.com>
* Apply suggestions from code review for wording
Co-authored-by: Max Desiatov <max@desiatov.com>
* Rename failedToFindDriver -> failedToFindWebDriver
* Rephrase diagnostic message
* Omit explicit internal keyword
* Remove unused goto.Response struct
* Add license header to Tests/WebDriverClientTests/WebDriverClientTests.swift
Co-authored-by: Max Desiatov <max@desiatov.com>
Co-authored-by: Max Desiatov <max@desiatov.com>
I am trying to implement an `esbuild` plugin that calls into `carton`. My plan was to call `carton bundle --debug` to get a quick development build and then extract that command's output for use in our esbuild project.
Unfortunately, `carton bundle` still runs `wasm-opt` even on a debug build, which takes 5-10s for our project. The only alternative I can see is `carton dev`, but that runs the dev server / watcher, which we don't want either for a one-off build.
Since changing the behaviour of `carton bundle --debug` to _not_ run `wasm-opt` may cause issues with backwards compatibility, @MaxDesiatov suggested we add a command line option `--wasm-optimizations {size, none}` instead, allowing users to specifically opt out of this behaviour.
In theory, this should allow us to distribute self-contained binaries on Linux. These wouldn't be statically linked completely, but at least they should no longer depend on a separate dynamic library file with Swift stdlib.
Related to https://github.com/swiftwasm/carton/issues/336.
* Add --skip-build option to carton test to delegate building to users
* Add test case for --skip-build
* Rename --skip-build to --bundle-path to allow specifying binary path
* Update Sources/CartonCLI/Commands/Test.swift
Co-authored-by: Max Desiatov <max@desiatov.com>
* Rename --bundle-path to --prebuilt-test-bundle-path
* Update Sources/CartonCLI/Commands/Test.swift
Co-authored-by: Max Desiatov <max@desiatov.com>
Co-authored-by: Max Desiatov <max@desiatov.com>
`FileSystem.isDirectory` returns `false` when running it on broken symlinks, which breaks Node.js tests flow. We should be able to clean up all symlinks, even broken ones. Other we can't create new correct symlinks because broken symlinks already exist at those paths.
After switching to `async`/`await` the value of `isBuildCurrentlyRunning` wasn't correctly reset, which led to issues. By resetting the variable in `defer` we guarantee that it will be reset even when errors are thrown.
Resolves#339.
We were reading custom `index.html` only once on launch, which meant people had to restart `carton dev` every time they've updated `index.html` during the build process to see changes they've made.
* Use JSKit runtime from SwiftPM resources
* Fix Node.js test runner
* Remove unused webpack npm packages
* Update Swift version in `.swiftformat`
* Fix browser and Node.js CJS/ESM handling
* Fix one of the tests, add CI time limit
* Use Tokamak `update-jskit` branch to fix tests
* Use latest Vapor with `.mjs` content-type fix
* Use dynamic import to detect JSKit presence
* Fix missing `runtimeConstructor` reference
* Update `StaticArchive.swift`
* Reduce the diff
* Address PR feedback
* Fix Node.js <-> JSKit integration test
* Update SwiftPM dependencies
* Fix comment typo in `testNode.js`
* Reuse `__stack_sanitizer` across entrypoints
* Refactoring the use of `DestinationEnvironment` and `Environment`
`Environment` shouldn't specify the concrete environment, but the type
of environments enough for build planning.
* Lower i64 imports only for WASI oriented things
### 🎩 What is the goal?
Implement NodeJS as another test runner.
### 📄 How is it being implemented?
In this PR, I include the following changes:
- Create an abstraction for the different Test Runners (Wasmer, browser and now Node)
- Implement the new Node test runner (quite similar to the Wasmer one)
- Unify Javascript client code, so we can make sure we apply the same patches and load in the same way all the different targets
- Create a new entry point for testing with node
- Add that new entry point to the static bundle
### 👀 Any consideration?
The Node test runner does not use the TestsParser as it heavily impacts execution time. I will try to figure out what's going on later.
### ✅ How can it be tested?
Testing is automated 🤖 . You can also check this in your own project by running:
```bash
carton test --environment node
```
Resolves https://github.com/swiftwasm/carton/issues/175.
I initially thought we should parse `Package.swift` manifests of the whole dependency tree to collect paths to resources from them, but now I'm not even sure that SwiftPM provides an API for this.
Much simpler solution is to serve with `dev` and copy with `bundle` all directories with `.resources` suffixes in the build directory. I think it's quite impossible to stumble upon unrelated directories with this approach, while it still resolves the issue as intended, in my opinion.
Yuta Saito