Resolver can't resolve library not transitively imported from primary input

[dam0vm3nt]

I've created a Builder that accept an HTML file as its primary input but needs to analyze some dart files to accomplish its task.

Trying to use buildStep.resolver.isLibrary(assetId) / getLibrary(assetId) with a valid dart library assetId always returns false or throws (the latter). It behaves like if the resolver didn't actually knows anything about the asset. This doesn't change even if a previously call canRead or readAsString on the same assets.

If I make the builder accept the dart file as primary input (only to investigate the problem) then the resolver works.

[natebosch]

Are you running wrapped as a Transformer with pub? I think the BarbackResolvers can only resolve libraries that are in the transitive imports of one of the primary inputs.

What is the use case for resolving a library which is not imported? Supporting resolution will be tough since the analyzer code expects files to be available synchronously while builds can only read assets asynchronously.

[dam0vm3nt]

No it's a bare Builder. I'd like to generate a new .html file from an existing one. The original one references some dart scripts in script like tag (e.g. : <script type='application/dart' src='scriptName'></script>). I need to use those scripts as entry-point to look for some kind of annotation in order to inject other html fragments. It's something very similar to the web-components transformer (html import inliner). But I want to do this in a Builder.

The strange thing is that I was expecting that calling resolver.getLibrary(assetId) would trigger the analysis even if that asset was not analyzed until that point and also introduce a dependency of the buildStep - but that seams not the case.

[dam0vm3nt]

... and the file I'm going to analyze is part of the current project, it doesn't resides in another - not imported - package.

[jakemac53]

Ya, this is a known issue that was a side effect of some of the simplification around the resolver apis.

Today you can only resolve dart code that is reachable from your primary input, primarily for performance reasons. When we move away from the barback_resolvers package we should be able to fix this.

[natebosch]

Yeah I think we stand a much better chance at resolving this in build_runner than when running with pub, I'm not sure of the approach but we'll definitely keep this in mind while we work on #348

[dam0vm3nt]

Ok. In the meanwhile I have resorted on using my own AnalysisContext. I'll revert using the BuildStep resolver once this is "fixed".