Lint to recommend using the direct file instead of library exporters

[jodinathan]

We are trying to improve the time to build our web apps.

In a talk with @jakemac53 at Gitter we found out that it is better to import only the file that has the Component you need to use instead of the whole library.

So it would be very helpful to have a lint to recommend to import the direct file instead of the library exporter.

Ie:

// lints to import the material_button file directly instead of the library
import 'package:angular_components/angular_components.dart'; 

@Component(directives: [MaterialButtonComponent])

[bwilkerson]

@jakemac53 Could you provide a bit of context for why this is better? It would help me understand the value of such a lint, and help when we're writing the documentation for the lint if we decide to add it.

[jakemac53]

For build_runner codegen in particular, the minimum cost of resolving any given library scales based on the number of transitive imports. All transitive imports are also added as dependencies (this is where that cost comes from), so it hurts invalidation.

This means importing less specific libraries comes with a real cost, especially if it is done consistently across the entire app.

[jakemac53]

Fwiw this has historically at least also affected both the analyzer and frontend server, although I do not know if this is still the case (I know there were at least efforts to do more fine grained invalidation).

[srawlins]

It sounds like we could write a lint rule which examine each import directive and every used element which is provided by that library (like MaterialButtonComponent), and then:

• if the element is not declared by the library which is imported (and therefore the element is provided by an export in that library),
• and the library where the element is declared is not implementation-private (lib/src/...),
• then the element is a candidate for more direct importing.

Then, if all elements for such an import directive are candidates, report that the import directive can be replaced with one or more direct imports.

If not all elements are candidates (meaning at least one is declared in the imported library, or at least one is declared in an implementation-private library, then nothing is reported.

To get more complex, but more accurate, we would do more careful examination of where the element comes from. For example:

• if you import 'package:foo/foo.dart' to get MyComponent,
• and 'package:foo/foo.dart' provides MyComponent via an export of 'package:foo/components.dart',
• and 'package:foo/components.dart' provides MyComponent via an export of 'package:foo/src/my_component.dart',
• and 'package:foo/src/my_component.dart' declares MyComponent,

then it would be great if the first import could be reported, saying "it's better to import 'package:foo/components.dart'. I don't know the algorithm you'd use though. I think it would be complex, involve heuristics, and be error-prone.

Most users would not want this lint rule, right? Most of the time, you should prefer to import the bundled package library. So this lint rule would only be recommended for users of build_runner?

[bwilkerson]

... this has historically at least also affected both the analyzer and frontend server ...

Yes, I believe that this would still impact invalidation in the analyzer. But the impact only occurs when the imported libraries are changed, so it has impact less often when we're talking about libraries in third-party packages (because those typically don't change very often). I'm not sure why this would impact build_runner, but I'll take your word for it.

Most of the time, you should prefer to import the bundled package library.

I don't know whether we actually give that advice (though analyzer kind of does by trying to recommend ways to reduce the total number of imports), but Flutter appears to promote it. I have to wonder how badly that's impacted Flutter users that use build_runner.

[jakemac53]

But the impact only occurs when the imported libraries are changed, so it has impact less often when we're talking about libraries in third-party packages (because those typically don't change very often).

While it is definitely true that third party packages are less likely to cause problems from an invalidation perspective, we don't know which packages are 3rd party packages. It isn't safe to assume any package other than the root package is such a package (and in particular internally it is common to touch files outside the "root" package, because packages are very small).

I'm not sure why this would impact build_runner, but I'll take your word for it.

It doesn't hurt the invalidation (any worse than other tools) but it affects the runtime performance. For every single library that is resolved, we must crawl the transitive dependency graph, even if those libraries have already been analyzed, in order to set up the dependencies for our own invalidation.

[jodinathan]

so it has impact less often when we're talking about libraries in third-party packages (because those typically don't change very often)

Both angular and angular_components are no longer synced out by Google, so we have to touch it quite a bit.

We also have custom UI libraries that encapsulate angular_components and other third party components, thus, any time that we touch a single and simple file the builder end up starting all over again.

I would definitely add this lint to all web packages but not on server side libs.

[jakemac53]

Yeah, I think it mostly is relevant for packages which heavily use build_runner based codegen (ie: angular). While there may be advantages more generally for compilers/analyzer those things are likely to get better over time and are anyways less impactful.