Vite for Kotlin 0.5.3 is out! This version contai...
# javascript
c
Vite for Kotlin 0.5.3 is out! This version contains: • Support for Kotlin 2.2.0 • Support for Gradle 8.14 • Deployment based on NMCP Full changelog#C078Z1QRHL3
👍 3
👀 2
t
I tried to add Vite for Kotlin to my project but got stuck on the configuration as I haven't been able to figure out how to port the config from webpack.config.js. Would be nice if you could add an example how to configure Vite for websocket proxy or historyFallback. I've read the documentation of course, but couldn't understand out how to actually write into the config apart adding plugins.
And on that note, it is just a personal opinion, but Dokka generated documentation is not as useful as a handful of examples about how to do things. I see many projects putting out the KDoc as "documentation", but I rarely read any of those to be honest. Too long, too deep.
c
There are examples here: https://gitlab.com/opensavvy/automation/kotlin-vite/-/tree/main/examples?ref_type=heads They don't use the websocket proxy, though.
Could you please create an issue that contains your webpack config and ideally an example project?
> I see many projects putting out the KDoc as "documentation", but I rarely read any of those to be honest. Too long, too deep. Yeah, I get that. There will soon be a new home page for the project (preview here). It's a difficult equilibrium because maintaining a non-dokka site up-to-date is a lot of work. Note that the Dokka output is already quite simplified and should be relatively easy to navigate, and all configuration options have an example.
t
Sure, an example project config: https://github.com/spxbhuhb/adaptive-mpw-example/blob/main/webpack.config.d/config.js I’ll add the issue later (I’m at the dentist right now).
🙏 1
c
Ahah good luck 🦷
t
Only control luckily.
Yes, writing docs is hard, I’ve built a full doc generation system for my project to ease this task.
About the config, I’ve checked vite and it seens easy to translate this into it. I just dont see how to inject the translated version into vite.config.js
c
I don't think we've mapped the websocket config yet, but if it's 1-1 I can probably add it very fast
t
Wouldn’t it be a better to simply add the possibility to inject anything into the config?
Or just supply the config manually. That way we could experiment easily without you spending time on the plugin.
t
It’s what we have in KFC. 😉
thank you color 1
🙌 1
You control config on 100%
t
I didn't know about that one, thank you, I'll check it out.
c
> Wouldn’t it be a better to simply add the possibility to inject anything into the config? There's upsides and downsides. The point of having the configuration controlled by Gradle is that it's easy for the plugin to preconfigure things to Just Work™. Also, it makes it possible to have different configuration for development for the final build, handling Gradle build cache, etc. At some point, I definitely should go through all config options and add them all, though.
Which ones do you need?
For example, we're currently working on having the plugin automatically set up everything for source maps to work.
t
Created an issue to show the content of the config: https://gitlab.com/opensavvy/automation/kotlin-vite/-/issues/59
Let me know if you need more information. Thank you.
c
Thanks! I'll take a look tomorrow.
thank you color 1
t
For example, we're currently working on having the plugin automatically set up everything for source maps to work.
We also solve this problem in default generated config. But it's easier to copy such block - it's not very big.
c
Do you have an example? I don't see it in the examples directory
t
c
@turansky How does this work? Rollup is only for the final bundle, so this does nothing in development mode, right? How does it know where to find the sources?
t
cc @Michael Porotkin
m
@CLOVIS, yeah, you're right, this does nothing in vite dev. Though we implemented a task which builds an app in dev mode (deobfuscated, unminified, with source maps), there's no much use of it. Thanks to per-file granularity which we're using, it's really easy to map files and debug in chrome dev tools instead
c
I really need to start using per-file granularity
Does it still break if there are two classes with the same name?
m
Nah, haven't experienced that these days. The only issue I dealt with is same fully qualified names clash with different source sets, but that wasn't K/JS-specific
c
So as long as the fully-qualified names are different,
useEsModules
and
per-file
should work?
👍 1