How to share logic/files between different npm packages?

[MangelMaxime]

Description

Hello,
I am currently working on Nacara which is a project that have several projects in it delivered in different npm package and can be consume by raw JavaScript. The problem is that each npm package has it's own versions of the same files.

For example, each package has it's own .fable/fable-library or even myProject/Types.fs.js

This leads to having a bigger package size and also some bugs/limitation. For example, I think I read somewhere that you can't test equality from project A on a type created in project B because they don't have the same constructor.

Is there any plan to solve this kind of situations? Re-introducing fable-library would be a step forward but would not fix the "sharing logic" part.

I am starting to think about the possibles solutions before doing anything. And would like to know if there are already some solution for that ?

[MangelMaxime]

One thing I just discovered is that you can stored anonymous record definition in a types

Which allows to keep the type safety of F# and also generate POJO in the output so no additional type just like you would have it in JavaScript.

type TestB =
    {|
        Type : int
    |}

let b : TestB = {| Type = 2 |}

generates:

export const b = {
    Type: 2,
};

And so because there is no type generation it is easy to "share" the code as there is nothing to share here ^^ But the problem come back if you want to share some helpers.

module TestB =

    let getName (v : TestB) =
        if v.Type = 1 then
            "Class"
        else
            "Function"

generates

export function TestBModule_getName(v) {
    if (v.Type === 1) {
        return "Class";
    }
    else {
        return "Function";
    }
}

and this function is then duplicated between the bundles.

[alfonsogarciacaro]

Yes, there's a similar issue #2282, but there are currently no plans to make F# code work seamlessly across bundles/npm packages. In similar situations (e.g. fable standalone and the fable repl app) I use interfaces to communicate between programs and as you already noticed anonymous records can be used for a similar purpose (although they have some limitations in F# when used across different projects).

If you have common helpers in different Nacara projects, I would have a common file with the interfaces, then export an implementation in the helpers project and import it from the other projects as if it were a JS library (because it is):

// Interfaces.fs, shared across projects
type Helper =
    abstract DoSomething(): unit
    abstract DoSomethingElse(): unit

// Helpers.fs, last file of helpers project
[<ExportDefault>]
let helpers =
  { new Helper with ... }

// ProjectA
let helper: Helper = importDefault "nacara-helpers"

About the fable-library, I forgot to tell you in #2489 there's a compiler argument to say where the fable-library is. This is used for example, to compile the Fable.Library itself:

Fable/build.fsx

Line 123 in c54668b

"--fableLib " + buildDir

But I would be very careful with this, if you publish a patch version of one of Nacara projects compiled with a different Fable version the fable-library it uses may not be aligned with other Nacara packages.

[kerams]

But I would be very careful with this, if you publish a patch version of one of Nacara projects compiled with a different Fable version the fable-library it uses may not be aligned with other Nacara packages.

Time for some assembly redirects-like goodness hell? :))

[MangelMaxime]

Yes, there's a similar issue #2282, but there are currently no plans to make F# code work seamlessly across bundles/npm packages.

Ah yes that's where I read about it but couldn't find it at the time of writing.

But I would be very careful with this, if you publish a patch version of one of Nacara projects compiled with a different Fable version the fable-library it uses may not be aligned with other Nacara packages.

Totally agree, with you I was just exploring the possibilities.

Thank you for the explanations, I will re-try having a "nice" organization of the code it make it easier than it is today to consume from JavaScript. And if I am still stuck will for now, accept the current situation of Nacara as I already spent way much more time on it than I wanted initially (as often on projects).

[alfonsogarciacaro]

Closing for now, please reopen if there's still something left unanswered.