https://kotlinlang.org
Join Slack
I still do not understand how I can compile `module-b`, which depends on `module-a` , without having...
# javascript
e
I still do not understand how I can compile 
module-b
, which depends on 
module-a
, without having K/JS bundle both of them together in a single npm library. I'd like 
module-b
to be compiled separately, and depend on the npm version of 
module-a
Both modules are Node.js libraries.
t
Which problem will be solved by separate NPM dependency?
e
@turansky I'd say advantages are negligible, the point is they're two separate artifacts, which should be deployed to npm on their own. Now, if I deploy 
module-b
, it's going to duplicate all 
module-a
content (which also means additional size)
t
It depends on library
When you build independent application you can use DCE on 100%
With library you lock some DCE options
e
Well, yes, but if you think about it, conceptually it makes sense to re-use a published artifact, if there is one. This also allow developing the two libraries asynchronously, example: you can update only 
module-a
, and a client of 
module-b
can just bring in the newer version of 
module-a
. DCE might miss stuff, but you get two lightweight packages instead of a light one and an heavy one because of duplication. Now, maybe I'm overthinking, in which case I'd be happy to just ditch the entire argument.
t
From my perspective such dependency is more problem than improvement
e
Well it's a fair opinion! Understandable. Do you recall if someone ever brought it up? Like, a YouTrack issue for example. I'd like to hear more opinions on this, especially from JB devs
a
I fully understand @Edoardo Luppi and I also have come to the same conclusion. We need a way to distribute these modules seperately. Exactly like how kotlin/jvm does when one publishes a library. The current approach is feasible if you intend to just build one library for a particular K/JS application. But building a standalone JS lib with kotlin/JS is not feasible with the current way of bundling and distributing things
💯 1
e
Maybe @Artem Kobzar knows if this was ever considered
a
If you are talking about the per file compilation, it is definetely a step closer to solve this issue
e
@andylamax it's true tho that DCE would have to be disabled, or would have to be reduced, but I'm ok with that.
a
It really is not a good approach applying DCE for a library. You can use it as a hack for sure. But given that a library is not the final executable, it makes little sense to start eliminating code on a library level
✔️ 1
e
@andylamax well the per file stuff works and that's OK. Even per module works and that's OK. But we really need a way to package the content of the module only, and not its dependencies too. If I compile 
module-b
, which depends on 
module-a
, i find both of them in an npm package named 
module-b
a
I would say, the goal should similar to the js ecosystem. A gradle submodule should directly translate into an npm module (with its own 
package.json
). All its dependencies should be declared in the 
dependencies
or 
(peer|optional)Dependencies
of the generated 
package.json
file, and should import the declaration as a normal javascript library
e
@andylamax yeah I agree, I was basically saying the same thing. Do you know how they do it in Space? I've read the use KJS for the front end.
a
So, if you are talking about Jetbrains Space. I know thy don't publish javascript libraries. They don't have that use case (to the extent of my knowledge), because they are building an app, a bundle with DCE, is sufficientl for them. Again, their goal is the Space Browser App, not some javascript library
c
Hello. I found this thread and was wondering if there were any updates for how JS modules are distributed. Is there a recommended way to distribute multiple libraries and allow integrating applications to handle the DCE? We have have a project with multiple modules and a common module shared between them (
module-a
, 
module-b
, 
common
). Both 
module-a
and 
module-b
depend on 
common
. The common module is bundled in both modules. It also looks like each module is getting a subset of the Kotlin standard library bundled with it instead of sharing the dependency.
e
Hey! That's the way to go (maybe unfortunately). In our case it wasn't a big deal because we distribute fairly large apps even without considering K/JS.
t
@Caleb 
module-a
and 
module-b
- applications or libraries (in your case)?
c
They're libraries.
e
There is currently no way to avoid including the common lib in both. We have 
A > C < B
too, and parts of C ends up in both of them, depending on the amount of API usages.
c
Ah, ok. Do you know if there's a Youtrack issue for handling dependencies more like individual npm modules like mentioned above?
e
Not that I'm aware of. However that would also require K/JS to compile everything with stable names (if you don't use 
@JsExport
), instead of outputting something different every time. Overall my suggestion is to not overthink it. Let's say you want to publish A, B, C. You'll publish them as self contained packages and that's it.
Most K/JS libs or apps will never be published via npm, simply because K/JS was not meant to be distributed that way. You can definitely do it if you need to distribute to JS consumers, but you'll have some usability issues like the one you just mentioned.
A practical example is adjacent teams asking us to share our libraries for them to consume via TS. Currently we decided to publish our Kotlin artifacts via Maven repos, to let them import and compile to fit their use case. We're planning to switch to publishing Node.js packages as soon as the TS consumer DX starts getting better (e.g. KDoc to TSDoc).
We might also be able to have workarounds once the per-file granularity is improved.
c
Ah, thank you for all the background info! Our libraries are integrated into apps running on some resource constrained devices. They're usually used together, so maybe we can look at making a single artifact out of them. Although it may not be an issue to have some duplication.
e
If you bundle your apps, having slightly bigger libraries from K/JS won't make it a problem. Here you find some options to reduce the output size. https://kotlinlang.slack.com/archives/C0B8L3U69/p1734536154962369
9 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by