Changes:
- added k/wasm target to library and demo
- added libs.versions.toml with coroutines version
Tested:
- using demo project
- publishToMavenLocal
I'll setup the test separately.
---------
Co-authored-by: Oleksandr.Karpovich <oleksandr.karpovich@jetbrains.com>
Reason: newer compose-core libs were built with kotlin 1.9.21. Previous
kotlin/native version 1.9.10 is not compatible with it.
Co-authored-by: Oleksandr.Karpovich <oleksandr.karpovich@jetbrains.com>
This commit changes the default resource routing behaviour:
- It used to search for a file in the root directory (on a domain level)
- After this change, it will search for a file relatively to the current
url segment
Besides that, we add a small configuration to let developers change the
default behaviour when needed.
___
usage examples:
```kotlin
// 1
configureWebResources {
setResourceFactory { path -> urlResource("/myApp1/resources/$path") }
}
// 2
configureWebResources {
setResourcelFactory { path -> urlResource("https://mycdn.com/myApp1/res/$path") }
}
```
___
This will fix https://github.com/JetBrains/compose-multiplatform/issues/3413 (currently it bothers our users)
Dowgrading to Kotlin 1.8 will allow to use `components` in Kotlin 1.8 and Kotlin 1.9 projects (iOS, JS targets). Now it is supported only in Kotlin 1.9 projects.
* Simplify resource management for iOS
Introduces new a new task 'sync<FRAMEWORK_CLASSIFIER>ComposeIosResources',
which collects resources from all source sets, included in iOS targets.
With this change:
* CocoaPods integration does not require any configuration or calling 'pod install' after changing resources.
* Important: existing projects need to remove 'extraSpecAttributes["resources"] = ...' from build scripts, and rerun `./gradlew podInstall` once!
* Without CocoaPods, the resource directory should be added to XCode build phases once.
Resolves#3073Resolves#3113Resolves#3066
* Move compose
* Update kotlin version to 1.6.20
* Move compose + Update kotlin version to 1.6.21
* Move compose to include a fix for compose plugin (kjs specific)
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
* move to kotlin 1.6.10-RC and corresponding compose commit
* Update path to the karma plugin we are patching
* Add ExperimentalComposeWebStyleApi
what worries me that this actually shows that there are some cases where without any changes apart version compiler people will have to worry about such annotations
* update kotlin version in templates to adopt 1.6.10-RC
* web: move ComposableWithNullableTypeParameter.kt to passing test cases
* update kotlin version in other places
* update imageviewer example: add OptIn for experimental API
* move compose
* move to kotlin 1.6.10 and corresponding compose
* move to kotlin 1.6.10 and corresponding compose
* move to 1.0.1-rc2
* move to 1.0.1-rc2 (todoapp)
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Co-authored-by: Shagen Ogandzhanian <shagen.ogandzhanian@jetbrains.com>
Remove:
```
__LATEST_COMPOSE_RELEASE_VERSION__
__KOTLIN_COMPOSE_VERSION__
System.getenv("COMPOSE_TEMPLATE_COMPOSE_VERSION")
```
They pollute templates/examples.
Now, all paths where we need to change the version are hardcoded in the script.
Usage:
```
./replace.sh 1.0.0-rc6
```
This script is planned to run on CI
In the future I will add support for changing Kotlin version