https://kotlinlang.org logo
Join Slack
Powered by
I'm adding js/wasmJs support to my androidx-sqlite...
# javascript
e
I'm adding js/wasmJs support to my androidx-sqlite driver for SqlDelight, and would greatly appreciate any feedback on the approach I'm taking (I don't have much experience with js/wasmJs in Kotlin, and I have even less in the js world in general).
❤️ 1
K 1
a
Overall it's great, thank you so much for adding web target 🙏 The only thing I've found is the added 
Regenerate package locks for release version
on CI. Lock file shouldn't be updated on CI and it should be stored in the repo (so everybody after cloning will have the same version of libraries). Could you please also share your experience with the 
webMain
was it easy to use or you've figured out any issue with it?
e
The only thing I've found is the added Regenerate package locks for release version on CI. Lock file shouldn't be updated on CI and it should be stored in the repo (so everybody after cloning will have the same version of libraries).
I've been doing this on all of my KMP libraries that support js/wasmJs since my releases are all completely automated through CI. If I don't do that on CI then the next build fails because the library version was bumped.
Could you please also share your experience with the webMain was it easy to use or you've figured out any issue with it?
It was definitely easier than the last time I tried it, but this was a pretty simple use of it.
thank you color 1
e
One thing I've noticed is this comment.
The Kotlin compiler also strips JS magic comments from 
js("...")
literals so 
import(/* webpackIgnore: true */ url)
doesn't survive either
This sounds like a good point to me. Should 
js
strip out comments? Maybe not since we are explicitly adding them.
a
It should not. There is a specific logic to keep those comments until webpack. If the compiler removes them, please create an issue ticket
thank you color 1
e
I'll let @eygraber create it since he already has a possible reproducer.
o
The only thing I've found is the added 
Regenerate package locks for release version
on CI. Lock file shouldn't be updated on CI and it should be stored in the repo (so everybody after cloning will have the same version of libraries).
TestBalloon also suffers from having to regenerate locks on CI. I have seen too many CI failures from spurious "Lock file was changed" after the lock files had been updated directly before pushing to the repo. KT-84782 captures the state of affairs, which I hope will be dealt with rather soon after being a persistent pain for such a long time.
a
@Adam Semenenko ^^
a
We had a recent report about the lockfile check failing on CI but not updating locally. Maybe it's caused by KGP skipping the install locally, and can be worked-around by deleting 
$projectDir/build/
before updating the lockfile locally. https://youtrack.jetbrains.com/issue/KT-86057/kotlinUpgradeYarnLock-skips-lock-file-regeneration-when-kotlinNpmInstall-is-up-to-date-causing-kotlinStoreYarnLock-to-fail
o
With TestBalloon, the release process starts locally with a clean build directory and deleted lock files, then updating the lock files and running local checks before committing and pushing to CI. But even with this setup, "lock file changed" conflicts appeared on CI. (Context: The project uses Npm instead of Yarn.) Additionally, the project also has an 
integration-test
subproject, copying of the lock file directory to several independent projects, which are created for this purpose. This worked most of the time, but sometimes the main Gradle project tasks ran fine, only to see the independent projects fail with "lock file changed".
a
We also suffer have the same issue. If we don't upgrade the lock file during CI it fails 😞
7 Views
Open in Slack
PreviousNext
Powered by