Explore splitting up into several entry points to improve code-splitting in clients

[robb-j]

For example,

• audio for broadcast & receiver logic and playing audio from a stream
• core for things that are always needed
• schedule for views and components related to schedule, what's on and session tiles
• session for views and components related to viewing and interacting with a session
• ???

The problem is that all bundled as one it is quite large, look more into code-splitting and sideEffects as alternatives too

[robb-j]

I've got rollup to generate multiple entry-points and configured the package.json with exports to export multiple files in the correct way.

I've struggled to get multiple entry-points working for a client (experimenting with the PlanetRed codebase). It seems there needs to be extra configuration so the typescript types can be used properly and they need to align with the exports so they all work well together.

I took inspiration from this blog post, for experimenting with the typesVersion but couldn't get it working properly. https://2ality.com/2021/07/simple-monorepos.html#producing-esm-modules-via-typescript.

There was an extra issue where if I used npm link to locally link my climatered-client to this repo, it would then fail to load the VueComponentOptions from vuex and vue-i18n so it would not build. It wouldn't accept the i18n and store parameters for new Vue({ ... }) inside App.vue. I'm not sure how those are linked, doing an npm ci removed the npm link and it worked again though.

[robb-j]

With the restructure I've kept the main entry-point (module.ts) so there should be no major breaking changes, once multi-entry-point is released, changes to imports & exports from any module should be considered breaking.

[robb-j]

I tried hacking around with the beta version to get multi-entry-points working ~ ``

I ended up hacking this into the node_module's package.json

{
  "exports": {
    "./": "./dist/deconf-ui.esm.js",
    "./atrium": "./dist/atrium.js",
    "./audio-lib": "./dist/audio-lib.js",
    "./content": "./dist/content.js",
    "./core": "./dist/core.js",
    "./dev": "./dist/dev.js",
    "./form": "./dist/form.js",
    "./lib": "./dist/lib.js",
    "./registration": "./dist/registration.js",
    "./schedule": "./dist/schedule.js",
    "./session": "./dist/session.js",
    "./store": "./dist/store.js"
  },
  "typesVersions": {
    "*": {
      "*": [
        "dist/types/*",
        "dist/types/*/module",
        "dist/types/module"
      ]
    }
  },
}

but it ends up with this warning:

This dependency was not found:

* @openlab/deconf-ui-toolkit/atrium in ./node_modules/cache-loader/dist/cjs.js??ref--14-0!./node_modules/babel-loader/lib!./node_modules/ts-loader??ref--14-2!./node_modules/cache-loader/dist/cjs.js??ref--0-0!./node_modules/vue-loader/lib??vue-loader-options!./src/App.vue?vue&type=script&lang=ts&

To install it, you can run: npm install --save @openlab/deconf-ui-toolkit/atrium

It seems the typesVersions is picked up as VSCode was seeing the correct types, after a Vetur reload, but the exports field had no effect.

I tried it with these import use cases

import * as deconf from '@openlab/deconf-ui-toolkit/atrium'
import * as deconf from '@openlab/deconf-ui-toolkit/atrium.js'

// It seems to work for this one, but it isn't what we want
import * as deconf from '@openlab/deconf-ui-toolkit/dist/atrium.js'

For the last one, if I console.log(deconf) it it seems to be the main module, not the specific atrium code.

[robb-j]

It seems overriding types specifically is the way to go:

{
  "types": "dist/types/module.d.ts",
  "typesVersions": {
    "*": {
      "atrium.js": ["./dist/types/atrium/module.d.ts"]
    }
  },
}

[robb-j]

It seems the "exports" field is only available in webpack 5, https://github.com/webpack/webpack/releases/tag/v5.0.0-beta.18.

I previously search on the v4.webpack site but the link took me to the v5 docs again, great.

[robb-j]

Ok, I don't think this is feasible to do without upgrading to vue3 or somehow getting to webpack 5. The restructure is still useful, but full splitting isn't possible at this time. This issue should be revisited later.

[robb-j]

How modules inter-relate should also be considered. For example, the "session" module relies on the "core" and SpeakerGrid from "schedule"