Question here for the room. We have a project with a main library and a shared library. We recentl...

# javascript

[Brandon Saunders]

Question here for the room. We have a project with a main library and a shared library. We recently moved some items from the main library to the shared library and noticed that they were no longer accessible from consumers of the main library. They could still be used within the main library but the JS runtime wasn’t able to reference any of them from their namespaces. Is there a known right workaround for this? For context we’re working in a multiplatform project but I don’t think that should impact this.

[turansky]

Do you use legacy compiler?

[Brandon Saunders]

I don’t believe so. How can I confirm?

[Brandon Saunders]

the issue seems to be that the class is not included within the items exported within the primary module. It’s not clear how to indicate that we would want some of the classes from the shared module to be exported as well

[Marc Knaup]

Please share more details about your project setup, errors, and so on.
Also, is the main project a Kotlin/JS project or a regular JS project that uses a shared Kotlin library?

[turansky]

@Brandon Saunders Look like you need additional DCE configuration

[Brandon Saunders]

entire thing is a kotlin multiplatform project with a JS output (among others). There are two main projects that get intentionally built and a shared project containing code in common between the two. We’re also using webpack to splitchunk the code currently, but the issue occurred before we made that change too. The code in the shared project is present in the JS output library but it is not exported so it can’t be referenced by the clients using the library.

[Brandon Saunders]

@turansky what is the additional DCE configuration that’s needed? We made a workaround where we’re exposing it from the shared library and pulling the shared library into our projects separately. However the problem is now there are two instances of the enum singleton, so they can’t be compared directly. We need to compare them on the name$ property, which feels weird.

[turansky]

Only public members of current subroject exported by default

[Brandon Saunders]

are you saying that in order to do this Kotlin would need to add a configuration to DCE to support it?

[Brandon Saunders]

if so, is importing the two projects the only method currently available for solving the problem of using shared classes? Why doesn’t a public method with a return value of the shared class export that class?

[turansky]

It's open question

[turansky]

You can solve this problem via manual entry point

[turansky]

Which will export both libraries

[Brandon Saunders]

what do you mean by manual entry point?

[turansky]

Do you use webpack distribution?

[Brandon Saunders]

yes

[turansky]

By default Kotlin use current project as webpack entry point

[turansky]

You can configure custom entry point and merge exports of libraries

[Brandon Saunders]

ah i see. Thank you we will try that

[turansky]

If you have 2 subprojects shared and app :
1. Add index.js to %app%/src/main/resources
2. Configure webpack main entry. For example via plugin
3. PROFIT
Common root package can be a problem

[turansky]

index.js example

import * as shared from 'shared'
import * as app from 'app'

export * from shared
export * from app