Open yury-yufimov opened 4 years ago
@natebosch For thoughts on whether these or other lints would be useful for ddc developers.
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.
These rules are also subject to change - it's an implementation detail. I don't think the linter is a good place.
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/exports1.dart
/lib/exports2.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