MPP JS client: Can't resolve 'text-encoding' #961
Comments
|
Hi @ralfstuckert, thanks for the report. |
|
Fixed in |
|
I am getting the same error on Ktor 1.2.5 and 1.3.0-beta1: |
|
I'm also getting this error for 1.2.5 and 1.3.0-beta-1. Would really appreciate a fix as it's holding up project development |
|
Same here |
|
same here for 1.2.6! |
|
see Kotlin/kotlinx-io#57 for my current work around |
|
Now also getting this on 1.3.2: |
|
I'm getting these kinds of errors too, I think its the errors caused by the interplay of some of these tools and the differences between how webpack vs. gradle vs. packages vs. node vs. client/server views inputs and outputs. I'm trying to do full stack multiplatform with src/(main and test) / (backend, common, frontend) folders as sourceSets. I'm trying to use three or three.js Below is my gradle file, if you see anything wrong with it don't hesitate to tell me I'm still learning all this. I added npm("text-encoding"), cleaned and built than ran my custom task and got the error below marked E1. https://www.npmjs.com/package/text-encoding indicates its no longer maintained; I don't recall how I got the reset of those messages to disappear, the one regarding action-something was the result of a missing common dependency if I recall correctly. This webpack error show'd up when I started playing with the function F1 below, when I run it inside F2 below all hell breaks lose and I get the errors listed in E2. But again I didn't see any real webpack messages until I started adding packages and writing the code for the F1 function. To summarize: Does anyone understand what's really going on here? If I had to guess I'd say the ktor client is so new and potentially obsolete perhaps it shouldn't be used at all (it's on version 1.3.2, I thought it is supposed to stay lockstep with kotlin versioning at 1.3.70)? Exhibits E1
F1 F2 E2
|
|
Duplicate of #1400? |
|
To fix this, I've added the following dependencies to my Gradle build: api(npm("text-encoding"))
api(npm("bufferutil"))
api(npm("utf-8-validate"))
api(npm("abort-controller"))
api(npm("fs"))This fixed the issue for me! |
|
Still a thing for ktor 1.3.2. Fortunately, @MrPowerGamerBR fix worked for me! |
|
Issue is also still present in 1.3.2-1.4-M2, but the workaround above fixes it |
|
For everyone who is struggling with this issue I have another solution which suits my needs better than adding the dependencies to build.gradle.kts. I have a full-stack multiplatform project, JVM and Browser targets for now. The dependency solution proposed by @MrPowerGamerBR worked for me as well, but that puts about 700 KB of code into my distribution output. That's a lot. So, I removed the dependencies and solved the problem by creating a "webpack.config.d" directory in my projet root and putting an "external.js" file into it with the following content. This might not work for everyone as you might actually need text-encodings but for me they are mostly pointless as I use code points instead of UTF-8. A very good article about the difference: What every JavaScript developer should know about Unicode |
|
I was also getting this error and @MrPowerGamerBR's fix above worked in development, but I was still getting runtime errors with production Webpack builds. Continuing down the rabbit-trail linked me to this snippet in the DCE docs, which fixed all my issues. For reference, my kotlin {
js("browser") {
browser {
dceTask {
// configure DCE to prevent runtime errors in production webpack builds
keep("ktor-ktor-io.\$\$importsForInline\$\$.ktor-ktor-io.io.ktor.utils.io")
}
// ... other Kotlin/JS browser configuration
}
}
// ... other targets
sourceSets{
val commonMain by getting {
dependencies {
api(kotlin("stdlib-common"))
api("org.jetbrains.kotlinx:kotlinx-serialization-runtime-common:$serializationVersion")
api("org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutinesVersion")
implementation("io.ktor:ktor-client-core:$ktorVersion")
}
}
val browserMain by getting {
dependencies {
implementation(kotlin("stdlib-js"))
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-js:$coroutinesVersion")
implementation("org.jetbrains.kotlinx:kotlinx-serialization-runtime-js:$serializationVersion")
implementation("org.jetbrains.kotlinx:kotlinx-html-js:$htmlVersion")
implementation("io.ktor:ktor-client-js:$ktorVersion")
implementation("io.ktor:ktor-client-websockets-js:$ktorVersion")
// declare NPM dependencies to fix bugs with ktor client build
implementation(npm("text-encoding"))
implementation(npm("bufferutil"))
implementation(npm("utf-8-validate"))
implementation(npm("abort-controller"))
implementation(npm("fs"))
}
// ... other sourceset configurations
}
}
} |
|
I actually gave up on multiproject plugin after 4 months with it. Breaks too many other plugins, very limited. I've been trying to replace it the last 2 days with gradle subprojects and so far, I like it a lot better.... I realized the only thing MP was buying me is the ability to share common kotlin code across platforms, that's all (what I really needed far more was the ability to organize as I saw fit and to be able to compile to multiple platforms; code sharing would be a plus though. I suspect/hope I'll be able to accomplish something like that with gradle alone; ATM the only critical code sharing needed is that my Kotlin JS compiles and gets served up inside my Kotlin JVM code (hope MPP isn't needed, praying)... later it might be nice to share kotlin iOS/Android business logic, but that would need to get injected into a flutter app so not sure what's gonna be possible or desirable. Still loving Ktor though! |
|
I've actually fought my way through it, still thinking it worth the effort on the long run. My reasoning is that I do some heavy operation transforms and having the exact same code on server and client side will be a very good. MPP is hard because it forces you to be very-very strict. And I actually like that because it forces me to put things to the right place. If I do something wrong, all hell breaks loose, but that's fine. I think of this as the next level of abstraction in programming. Not needed for every task and it is not for everyone, but in the right hands it is very-very powerful. |
My related reasoning for switching is that gradle should be able to compile any language to anything it is capable of compiling too, and putting it where I need it... MPP really can't be doing much else under the hood.
I agree it forces you into a pigeon hole of whatever they thought 'they' (not the world) needed. It is so strict, it doesn't allow the use of the appengine plugin in the same gradle file, yet it doesn't account deployment or the view layer of apps only the business layer... so I am not sure how, within this inflexible strict system, they expect me to implement ios android view logic (definitely want an integrated project, that's why I'm using gradle in the first place! lol
I can't stand it, hate it with passion... I'm a computer engineer, I've had probably 10 classes on software lifecycles... what do I care about the opinion of one company or set of programmers? I don't unless they are providing me with a great engineering tool, like gradle... but MPP is an engineered product not a tool IMHO, yet its for developers so there is no logic in it to me after all this time with it, and 2 days without it. e.g. I have 3 codebases now... srcApp, srcWeb, srcBuild... trying to accomplish that with MPP anywhere in the project proved futile.
I agree with you that it could have and should be this, but I fear it is not because of this "...it forces you to be very-very strict. "... abstraction + inflexibility = pretty dam pointless for an engineer
In reality I think they were talking about building plugins in buildSrc instead of inside a gradle file.... but I've decided to interpret that differently, that you shouldn't use plugin at all... and life has been grand ever since... where I was bllind now I can see. I avoid em like the plague and when I do use one, generally carefully an isolated as much as possible to prevent me from beating my head open against a brick wall labeled gradle plugins. |
|
Check this out: Source If I'm not mistaken, there is your code sharing right there, without MPP, pure gradle 1 line. Could very well be wrong, never a java expert and learning lots of new tools here. Just FYI research. |
|
Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks. |
|
Works in |
Ktor Version
1.1.2
Ktor Engine Used(client or server and name)
Ktor client with default engine
JVM Version, Operating System and Relevant Context
JDK 1.8, Windows, Kotlin JS
Feedback
We are using the ktor client in a multiplatform project (android, iOS and web). Starting with version 1.1.0 the build of the JS client fails with the following message:
If I manually add
text-encodingas a npm-dependeny, it works.If I list the npm dependency tree with the previous working ktor version 1.0.1 I get:
If I list the npm dependency tree with a ktor version >= 1.1.0 the
kotlinx-io-js(and of coursetext-encoding) is missingThe text was updated successfully, but these errors were encountered: