FluidFramework icon indicating copy to clipboard operation
FluidFramework copied to clipboard

Make sure all package have ESM and `modules` at least, with no cycles

Open dzearing opened this issue 2 years ago • 5 comments

Feature

Please make sure all packages have a module entry that points to an esm entry point for the package.

Right now the local-driver package is missing one:

https://unpkg.com/@fluidframework/[email protected]/package.json

It also has a cycle in the import graph that esbuild complains about:

../../node_modules/@fluidframework/local-driver/dist/index.js -> 
../../node_modules/@fluidframework/local-driver/dist/localDocumentService.js -> 
../../node_modules/@fluidframework/local-driver/dist/index.js

Due to this in localDocumentService.ts:

import {
	LocalDeltaStorageService,
	LocalDocumentDeltaConnection,
	LocalDocumentStorageService,
} from ".";

Easy fix here; just change the "." to the appropriate source. Otherwise your modules may not emit in the order the index specifies which can lead to runtime issues.

Might be good to ask how to prevent cycle imports in the future (esbuild will report it, there are also tools like madge. Importing from barrel files within the package can lead to these cycles very easily, good to avoid.

dzearing avatar Feb 24 '23 01:02 dzearing

I have fixed the specific cases highlighted here, but not fixed other similar issues nor added tooling to catch these automatically. Thus this issue should stay open to track that work (which is not something I'm working on).

CraigMacomber avatar May 17 '23 22:05 CraigMacomber

@CraigMacomber You can get pretty far with just eslint rules. Some ideas:

Disallow from importing from barrel files and .. Only import from source directly and avoid barrel files. This does 3 things:

  • You can avoid implicit cycles
  • Build tools have potentially less work to do, speeding things up
  • It encourages smaller packages (when packages get big, we tend to add index files to manage import complexity. Instead use separate packages. Smaller packages === more versioning options, smaller more well-defined package api surface, and in tooling we can leverage package boundaries to improve speed.

dzearing avatar May 22 '23 18:05 dzearing

@dzearing Can you share the eslint rules you're referring to?

tylerbutler avatar Jun 07 '23 15:06 tylerbutler

@dzearing i also find the "smaller packages === better" comment interesting. We're struggling under the weight of the hundreds of packages we already have, so it's hard for me to wrap my mind around a model where we produce even more packages.

tylerbutler avatar Jun 07 '23 15:06 tylerbutler

This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!

This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!