Dart Analysis says "Target of URI doesn't exist:" when importing new package

[bjornbjorn]

This used to work fine but after upgrading IntelliJ and/or the Dart plugin the analysis can't seem to find the new packages i add to pubspec.yaml.

To reproduce:

1. Add a new package to pubspec.yaml (in my case I just tested by adding contact_picker: "^0.0.1+2")
2. Click "Packages get"
3. Import the package somewhere: import 'package:contact_picker/contact_picker.dart';

I get "Target of URI doesn't exist:" like this:

I'm able to use the methods that come with the package though so everything works fine, its just the Analysis that doesn't recognise the package.

Solution:
CMD -> Shift -> A (Find Action) -> Search for "Dart Analysis" -> Click the icon that says "Restart the Dart Analysis server" -> The red underline disappears from the package import and everything works.

IntelliJ Version

IntelliJ IDEA 2017.2.4
Build #IU-172.4155.36, built on September 11, 2017
Licensed to IntelliJ IDEA Evaluator
Expiration date: September 27, 2017
JRE: 1.8.0_152-release-915-b11 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.6

with Dart plugin Version: 172.4155.35

[devoncarew]

@scheglov, what triggers a re-analysis of a compilation unit? A change to the .packages file? A change to a referenced package: file? What if the reference does not exist on disk, but after a pub get, it does?

[scheglov]

When you change .packages file, this means that now SourceFactory is different and we need to recreate the AnalysisDriver and reanalyze. AFAIK we don't listen for .packages file modification. Basically, we expect users to do exactly this - click "Restart Dart Analysis Server".

We read a file only when we create FileState for the first time, because there is another files that references it; or when we get notification that the file was changes. If we read the file first time and it does not exist, we pretend that it exists, but is empty. And because nobody watches the Pub cache, we never reread it, unless we recreate AnalysisDriver. This is important to avoid performing I/O in order to keep performance reasonable.

[MikeMitterer]

This problem is vacant since x-years. As always cmdline works but IJ-analyzer fails. In my case restarting the analyzer via IJ (in this case PyCharm) didn't help.

[DanTup]

I've noticed this too, and had it raised today. How involved is fixing it in the server (I don't mind having a go with some guidance)? (as a workaround we could restart the server from the client, but it's a bit expensive to re-analyze the whole project so it feels a bit overkill).

[scheglov]

If changes to .packages file don't affect resolution, restarting DAS will not analyze anything.

You will pay for new Dart VM start, cold code execution, reading all files in all analysis roots, and reading analysis results cached from the file system. But not for analysis itself :-)

The state of ContextManager and (c) is a mess. We plan to switch it to the new analyzer API and might introduce something better, but until then fixing this issue is not practical IMHO.

[DanTup]

If changes to .packages file don't affect resolution, restarting DAS will not analyze anything.

I'm not sure I understand - if I restart the server, doesn't it need to analyze the project again when it restarts and I set the analysis roots? (it certainly seems like that - if I restart the server VS Code shows that it's analyzing).

but until then fixing this issue is not practical IMHO

Understood, thanks!

[cokobware]

F

[scheglov]

DAS caches analysis results in form of computed errors and indexes in the file system, and if there were no changes to files, it reads these analysis results from the file system, without analyzing anything. Affected files, which directly or indirectly use changed files, will be reanalyzed. The file that you open, so subscribe for its navigation and semantic highlighting, will be analyzed, because these features require resolved AST.

[DanTup]

DAS caches analysis results in form of computed errors and indexes in the file system, and if there were no changes to files, it reads these analysis results from the file system, without analyzing anything.

Aha, I didn't realise that :-)

If a fix in the server isn't trivial, I wonder if it's worth adding a flag in VS Code to automatically restart the server when .packages changes. It can be opt-in (for now at least) so people can try it out if they're prefer (I got into the habit of just reloading the window whenever I see it fail, but it doesn't seem like a good thing to tell end users to do).

[bwilkerson]

Is there any reason why AnalysisDriver cannot listen for changes to the .packages file and re-analyze files when it changes?

Should the content of the .packages file be part of the hash of analyzed files so that if it's different we won't use the cached data?

[scheglov]

AnalysisDriver itself does not listen for any file changes, it is up to the client to notify that a Dart file changed, or reconfigure with a new SourceFactory.

The whole content of the .packages file does not need to be part of the hash, because not all files are affected by a change. Usually only resolution of a handful of package: URIs is affected, and corresponding files and their clients should be reanalyzed. But the rest is not affected. AnalysisDriver depends on .packages indirectly through URI resolution, so files contents.

[bwilkerson]

... it is up to the client ...

To be clear, for other readers, you mean clients of AnalysisDriver, such as the analysis server, not clients of the analysis server protocol.

So, I'll re-ask the question: Is there any reason why clients of AnalysisDriver cannot listen for changes to the .packages file and reconfigure the SourceFactory when it changes? What I want to know is whether this is something that we can fix at this point or whether there are still blockers.

AnalysisDriver depends on .packages indirectly through URI resolution, so files contents.

So we potentially have enough information to know whether the cached data is still valid? The point of my original question, of course, is that I think we ought to figure this out on restart, not just assume that the state of the files hasn't changed since the data was cached.

[scheglov]

I don't see any blockers for listening .packages changes.

No, we don't assume that the state of the files hasn't changed, we read every file on start, and if their content happens to be the same, then we reuse analysis results.

[hipimy]

Im facing same issues when add a new packages to pubspec.yaml.
So i need to close the android studio or invalidate cache every time to make sure the packages can be found.

Android Studio 3.3.1
Build #AI-182.5107.16.33.5264788, built on January 29, 2019
JRE: 1.8.0_152-release-1248-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, v1.0.0, on Microsoft Windows [Version 10.0.17134.407], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK 28.0.3)
[√] Android Studio (version 3.3)
[√] IntelliJ IDEA Community Edition (version 2018.2)
[!] VS Code, 64-bit edition (version 1.30.1)
[√] Connected device (1 available)

[DanTup]

@scheglov do you know if anything has changed here? I can't reproduce this with the instructions at the top - when I add the contact_picker import, it's just green (unused) not red (missing).

[scheglov]

Not sure, it seems that quite a long time passed between the day when this issue was reported, and now. I saw yesterday that now DAS listens for .packages changes, and re-configures AnalysisDriver URI resolution. So, it might have been fixed.

[bjornbjorn]

FWIW I'm not reproducing this anymore either.

[DanTup]

Great, then I think it's safe to assume it's fixed. We can re-open if anyone sees it again on a new-ish build.

[Onpointiscake]

In my case it was just a problem with Visual Studio Code.
Solved by clicking in the lightbulb and selecting "convert to absolute" or something like that

[NickYoung-max]

In my case on window platform, I delete the file in 'AppData\Local\Pub\Cache' and then run 'flutter pub get' solved my problem.