The Fluid Framework is a library for building distributed, real-time collaborative web applications using JavaScript or TypeScript.
You may be here because you want to...
- Learn more about the Fluid Framework
- Build a Fluid object
Documentation and guides can be found at https://fluidframework.com/.
Hello World repo can be found at https://github.com/microsoft/FluidHelloWorld.
Core Examples repo can be found at https://github.com/microsoft/FluidExamples.
Have questions? Engage with other Fluid Framework users and developers in the Discussions section of our GitHub repo.
When taking a dependency on a Fluid Framework library, we recommend using a ^
(caret) version range, such as ^1.3.4
.
While Fluid Framework libraries may use different ranges with interdependencies between other Fluid Framework libraries,
library consumers should always prefer ^
.
Note that when depending on a library version of the form 2.0.0-internal.x.y.z
, called the Fluid internal version scheme,
you must use a >= <
dependency range (such as >=2.0.0-internal.x.y.z <2.0.0-internal.w.0.0
where w
is x+1
).
Standard ^
and ~
ranges will not work as expected.
See the @fluid-tools/version-tools
package for more information including tools to convert between version schemes.
The core code for both the Fluid client packages and the reference ordering service is contained within this repo.
The repo structure is somewhat unique because it contains several pnpm workspaces: some for individual packages and some for larger collections which we call "release groups". The workspaces are versioned separately from one another, but internally all packages in a workspaces are versioned together.
These workspaces do not align with package namespaces, and also don't always correspond to a single directory of this repo.
Here's the list of release group workspaces:
- client (previously known as "Fluid Framework Client" or "core") (Rooted in ./. Configured by ./pnpm-workspace.yaml)
- ./packages (Published in the
@fluidframework/
namespace, but some in@fluid-tools
and unpublished packages in@fluid-internal/
) - ./experimental (Published in the
@fluid-experimental/
namespace) - ./examples (Not published, live in the
@fluid-example/
namespace) - ./azure. (Published in the
@fluidframework/
namespace)
- ./packages (Published in the
- routerlicious (Reference Fluid Ordering Service) (Rooted in ./server/routerlicious. Configured by ./server/routerlicious/lerna.json)
- Packages (Published in the
@fluidframework/
namespace)
- Packages (Published in the
- gitrest (Rooted in ./server/gitrest. Configured by ./server/gitrest/lerna.json)
- Packages (Published in the
@fluidframework/
namespace)
- Packages (Published in the
- historian (Rooted in ./server/historian. Configured by ./server/historian/lerna.json)
- Packages (Published in the
@fluidframework/
namespace)
- Packages (Published in the
- build-tools (Rooted in ./build-tools. Configured by ./build-tools/lerna.json)
- Packages (Published in a mix of
@fluidframework/
and@fluid-tools/
namespaces)
- Packages (Published in a mix of
Here's a list of other sets of other packages (each package within these groups is versioned independently, forming its own release group):
- "Common" Packages: miscellaneous packages in the ./common directory and published under the
@fluidframework/
namespace. Most of these (but not all) have "common" in their package name. Packages which are used by multiple other groups of packages (such as built tools, linter configs and protocol definitions) live here. - "Tools" Packages: miscellaneous packages in the ./tools directory and published under a variety of namespaces. Logically about the same as "Common", but most of the names include "tools" instead of "common".
- Auxiliary Microservice Packages (supporting Routerlicious)
- ./server excluding routerlicious, gitrest and historian (Published in the
@fluidframework/
namespace)
- ./server excluding routerlicious, gitrest and historian (Published in the
- ./docs: The code and content for https://fluidframework.com.
Dependencies between packages in various layers of the system are enforced via a build step called layer-check. You can view the full list of packages and layers in PACKAGES.md.
Install the required tools:
- Git.
- + Git LFS
- Node.js: install the version noted in in the .nvmrc file. See NodeJs Installation for details.
Clone a copy of the repo and change to the repo root directory:
git clone https://github.com/microsoft/FluidFramework.git
cd FluidFramework
Enable NodeJs's corepack:
corepack enable
Run the following to build the client packages:
pnpm install
npm run build:fast
See also: Contributing
We recommend using nvm (for Windows or MacOS/Linux) or fnm to install Node.js. This ensures you stay at the correct version while allowing other uses of NodeJS to use the (possibly different) versions they need side-by-side.
Because of a transitive dependency on a native addon module, you'll also need to ensure that you have the prerequisites for node-gyp
.
Depending on your operating system, you'll have slightly different installation requirements (these are largely copied from node-gyp
's documentation):
The node installer should ask if you want to install "Tools for Native Modules." If you check the box for this nothing further should be needed. Otherwise, you can follow the steps listed here
- Python v3.7, v3.8, v3.9, or v3.10
make
- A C/C++ toolchain (like GCC)
If you've upgraded your Mac to Catalina or higher, you may need to follow these instructions.
- Python v3.7, v3.8, v3.9, or v3.10
XCode Command Line Tools
, which will installmake
,clang
, andclang++
- You can install these by running
xcode-select --install
from a command line.
- You can install these by running
- Building server/Routerlicious
- Refer to that package's README for additional requirements.
- Note that these requirements do not affect all workflows (e.g. the one noted above), but will affect workflows that include the packages under
server
(e.g.fluid-build --symlink:full
).
- Ensure that you have enabled running Powershell scripts by setting your environment's Execution Policy.
You can run all of our tests from the root of the repo, or you can run a scoped set of tests by running the test
command from the package you're interested in.
Note: Some of the tests depend on test collateral that lives in a submodule here: https://github.com/microsoft/FluidFrameworkTestData. You may choose to fetch that collateral into your local repository, which is required to run all the tests - otherwise some will be skipped.
First, ensure you have installed Git LFS. Then, from the repo root:
git lfs install
git submodule init
git submodule update
npm run test
npm run test:coverage
Our CI pipelines run on Linux machines, and the npm scripts all have the ci
prefix.
To replicate the test steps from the CI pipeline locally, run the following commands for the packages or pnpm workspaces:
Run | Non-Windows | Windows |
---|---|---|
PR | npm run ci:test |
npm run test:report && npm run test:copyresults |
Official | npm run ci:test:coverage |
npm run test:coverage && npm run test:copyresults |
We've checked in VS Code configuration
enabling F5 from a spec.ts
file to run those tests if you set the debug configuration to "Debug Current Test".
This will use an in-memory implementation of the Fluid server to sync between the two panes in the browser window.
- Choose an example under
/examples
- Navigate to the example's directory, e.g.
/examples/data-objects/clicker
npm run start
- Browse to http://localhost:8080 to interact with two copies of the example side-by-side
This will run the local Fluid server implementation we call "Tinylicious", so you can sync between multiple browser instances.
First, start Tinylicious by running these commands from /server/tinylicious
:
npm install
npm run build
npm run start
Then:
- Navigate to the example of your choice (same as above)
npm run start:tinylicious
- Browse to http://localhost:8080, copy the full URL you're redirected to, and open in a second window to collaborate
This repository uses prettier as its code formatter. Right now, this is implemented on a per-package basis, with a shared base configuration.
- To run
prettier
on your code, runnpm run format
from the appropriate package or release group, or runnpm run format:changed
from the root of the repo to format only files changed since the main branch. If your change is for the next branch instead, you can runnpm run format:changed:next
. - To run
prettier
with fluid-build, you can specify "format" via the script argument:fluid-build -t format
ornpm run build:fast -- -t format
To ensure our formatting remains consistent, we run a formatting check as a part of each package's lint
script.
Our workspace configuration specifies prettier
as the default formatter.
Please do not change this.
It is not configured to do any formatting automatically, however. This is intentional, to ensure that each developer can work formatting into their workflow as they see fit. If you wish to configure your setup to format on save/paste/etc., please feel free to update your user preferences to do so.
Notable setting options:
format on save
format on paste
Run the following command in each of your repositories to ignore formatting changes in git blame commands: git config --local blame.ignoreRevsFile .git-blame-ignore-revs
The root package.json in the repo includes devDependencies on the mocha and jest testing tools. This is to enable easier test running and debugging using VSCode. However, this makes it possible for projects to have a 'phantom dependency' on these tools. That is, because mocha/jest is always available in the root, projects in the repo will be able to find mocha/jest even if they don't express a dependency on those packages in their package.json. We have lint rules in place to prevent phantom dependencies from being introduced but they're not foolproof.
There are many ways to contribute to Fluid.
- Participate in Q&A in our GitHub Discussions.
- Submit bugs and help us verify fixes as they are checked in.
- Review the source code changes.
- Contribute bug fixes.
Detailed instructions for working in the repo can be found in the Wiki.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.
This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services. Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.