dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.3k stars 1.59k forks source link

Implement rules, which can help reduce number of compiled *.ddc.js modules #58106

Open yury-yufimov opened 4 years ago

yury-yufimov commented 4 years ago

Motivation While developing web application using DartDevC, you have no much options to manage number of compiled *.ddc.js files. In some applications it can go up to hundreds and thousands of js files, loaded on every browser refresh. Rules, how source files combined into ddc modules are described here: https://dart.dev/tools/dartdevc/faq#how-are-the-modules-created

The only linter rule to help is _implementationimports Besides protecting you from braking changes after minor update (in lib/src) in imported library, it helps DartDevC not to compile separate ("shared") module for every file from lib/src that is imported from other package.

But there are other situations which result in increase of ddc modules amount.

Suggestion Rule1: _implementation_imports_withinpackage

When you have _mypackage/web/demo.dart with import package:my_package/src/any_file.dart

that forces DartDevC to compile _my_package/lib/src/anyfile.dart as separate(shared) module, even if it is exported in __my_package/lib/mypackage.dart

Rule2: _entrypointimports

Let's assume you have library with structure

/lib/src/class1.dart
/lib/src/class2.dart
/lib/src/class3.dart
/lib/exports1.dart
/lib/exports2.dart

/lib/exports1.dart

export 'src/class1.dart';
export 'src/class2.dart';

/lib/exports2.dart

import 'exports1.dart';
export 'src/class3.dart';

DartDevC sees, that class1.dart and class2.dart are reachable from both entrypoints (exports1 and exports2), so, them are compiled as separate ddc.js files.

Rule should warn user, if one entrypoint (file under /lib, but not /lib/src/) imports/exports another

bwilkerson commented 4 years ago

@natebosch For thoughts on whether these or other lints would be useful for ddc developers.

natebosch commented 4 years ago

cc @jakemac53

I'm not sure if it would be best as lints or as a separate tool to explore what the modules are and why. My intuition is that it will be difficult to add much value with a linter since those would point at a specific import/export, whereas the module structure can be impacted by multiple factors altogether.

jakemac53 commented 4 years ago

These rules are also subject to change - it's an implementation detail. I don't think the linter is a good place.