Single Fluid Framework Library Package

[SamBroner]

Getting some initial thoughts on paper here.

We have the fluid-experimental namespace on NPM. We should use that namespace to experiment with a single library that import->exports all of our existing libraries.

I think we could (should?) also create aqueduct v2 export that has some of our thinking about pre-built data objects. This could include a Key Value Pair, 2d-array data object, etc.

Goals:

1. Reduce number of npm packages that a user needs to install before using the majority of the framework (80/20 rule)
2. Reduce the number of import statements a user needs to write in code, alleviating the need to determine which import contains which function/interface
3. More easily promote the 'public' facing APIs vs those that would be used for less common scenarios
4. Reduce the public API of existing packages to those methods/interfaces that we expect them to use (is this true?)
5. Make dependabot updating easier by being able to bump all Fluid packages with a single PR

[SamBroner]

@micahgodbolt & @curtisman. I figured both of you would be interested in this issue. I'd love to get clarity on how we should best organize the package.

[SamBroner]

First Pass:

Where should we make it?

Location: FluidFramework/packages/framework/fluid-library?
Name: @fluid-experimental/aqueduct

What should export?

Two Options

1. Export everything from 1 package
2. Export a specific subset of interfaces -> these should be everything you need.

If we export only a subset we need to export

• All the DDSs
• All the DataObjects
• Everything else? Looking at @micahgodbolt to prune down that list if possible. Can we get a minimum package set?

What should the namespaces look like?

They should roughly mimic our existing package structure.

Should we come up with a library tree structure to organize the package? This could use a spec, or we can iterate on it over time.

import { aqueduct, container-definitions } from "@fluid-experimental/main"
aqueduct.getTinyliciousContainer()
export container extends container-definitions.IContainer {

}

or

import { getTinyliciousContainer, IContainer } from "@fluid-experimental/main"
getTinyliciousContainer()
export container extends IContainer { }

Open Questions

Are there libraries that we can exclude from this package?

[micahgodbolt]

@SamBroner question about size:

Are we concerned about the package size of this import? Or do we see this as being the same as importing all of these packages individually, and that the user will treeshake out any unused code?

[SamBroner]

We can expect people to treeshake. Ultimately I want to get the size of this package down, but let's optimize later.

[micahgodbolt]

This is complete. We're got further work to refine the package contents, but that can be done elsewhere.

[LarsKemmann]

@micahgodbolt Where is this? Is it @fluid-experimental/aqueduct? And yes, please include everything in a single package; treeshaking should be taken for granted. :)