Closed gmpassos closed 1 year ago
- If possible, show the line that imports this dependency, specially if the line is in the current project/package.
- Show in the warning the exactly dependency with problems.
It should be listing the libraries that had the non-browser dependencies - if it isn't and you have a reproduction case we can look at that would be great.
- webdev serve using cached builds, needs to show, again, the warning, informing a skipped entrypoint.
We only show errors on subsequent builds, not warnings (the warning was a part of a cached build action). We could consider adding an option to upgrade this to a Severe log, which would make the entire build fail but it would show you the error on each build. Would that help?
(Error logs are cached and re-logged even if the action itself is not re-ran)
We could also consider similarly caching and re-logging warnings. cc @natebosch for thoughts on that.
- An extra suggestion is a command pub get -clean and a webdev build/serve -clean (you got the idea). Many build frameworks in the past, have the clean option, to ensure that caches are being removed (for decades this saved many developers).
There is a clean
command in build_runner (which webdev is using under the covers). You can do pub run build_runner clean
to have it clean things up. We should probably add a clean command to webdev too though. cc @grouma @kevmoo any reason we haven't done that?
We could also consider similarly caching and re-logging warnings.
We could try it out. I can't remember if there are cases where we expect this to happen though - do we have this warning if you have a mix between web and VM tests today for instance? If some fraction of users get warnings on every build and it's safe for them to ignore I'm worried about adding noise and training users to ignore it.
We should probably add a clean command to webdev too though.
Ideally clean
should be a last resort and we hope that most users shouldn't need to use it. My preference would be to push for a doctor
command which could be the first thing users try, focused on finding configuration or environment issues and clear up confusion. That command could offer to perform a clean. Unfortunately that's a much harder solution and we can't do that soon, so exposing clean
could be an OK stopgap.
+1 to the doctor command. Exposing a clean command as a stopgap is fine with me as well. Tracking issue: https://github.com/dart-lang/webdev/issues/1032
If possible, show the line that imports this dependency, specially if the line is in the current project/package.
This is important.
Is it possible to know which files are importing a file that is importing dart:io?
Is it possible to know which files are importing a file that is importing dart:io?
Again, it is supposed to be logging this. If it isn't please give repro instructions.
Another option is to use the import_path package, although it looks like I need to update that for the latest analyzer, and I am not sure if it can handle generated to cache files or not.
@jakemac53 it says the file the has the dart:io usage (dartis package) but not the one that imports the dartis package:
[WARNING] build_web_compilers:entrypoint on web/main.dart:
Skipping compiling pagebuilder_front|web/main.dart with ddc because some of its
transitive libraries have sdk dependencies that not supported on this platform:
dartis|lib/src/client/connection.dart
dartis|lib/src/protocol/reader.dart
dartis|lib/src/protocol/writer.dart
https://github.com/dart-lang/build/blob/master/docs/faq.md#how-can-i-resolve-skipped-compiling-warnings
@jakemac53 unfortunately the import_path doesn't seem to work with generated to cache files.
dart pub global run import_path web/main.dart package:dartis/dartis.dart
Unhandled exception:
FileSystemException: Cannot open file, path = '/Users/jonathanrezende/Projects/page_builder/web/pagebuilder_front/lib/app_component.template.dart' (OS Error: No such file or directory, errno = 2)
#0 _File.throwIfError (dart:io/file_impl.dart:635:7)
#1 _File.openSync (dart:io/file_impl.dart:479:5)
#2 _File.readAsBytesSync (dart:io/file_impl.dart:539:18)
#3 _File.readAsStringSync (dart:io/file_impl.dart:584:18)
#4 _importsFor (file:///Users/jonathanrezende/.pub-cache/hosted/pub.dartlang.org/import_path-1.0.2/bin/import_path.dart:55:33)
#5 main (file:///Users/jonathanrezende/.pub-cache/hosted/pub.dartlang.org/import_path-1.0.2/bin/import_path.dart:35:22)
<asynchronous suspension>
also, weirdly I couldn't run directly import_path command after activating it through dart pug global activate.
Ah ok, so you want the full import path. I think we previously decided it was better to leave that up to other tools (it might actually be quite expensive to compute, and the output very noisy).
If we made this an error instead of a warning, then I could see it, as we wouldn't regress workflows for people who are just ignoring the warning right now.
so you want the full import path
We might want to show the imports in root package libraries that transitively import dart:io
.
Maybe only the last in the chain that is still in the root package, or maybe the full path from the not compiled entrypoint to the last in the root package. The actual chain of imports in dependency packages is probably not as important.
@jakemac53 @natebosch do you know what we could do now?
This is seriously harming our team :(
@jodinathan I am looking at fixing up import_path to work with generated files and the latest analyzer.
Ok, I published version 1.1.0 let me know if that works for you
it worked! thanks @jakemac53 !
it was an annotation that had one argument that the source were importing the dartis package.
I thought that annotations were completely erased from the building process
I thought that annotations were completely erased from the building process
Even if they were, the import wouldn't be dropped, in particular for modular compiles we have to compile dependencies first, so we don't know if the import is used or not until after it has been compiled.
See https://github.com/dart-lang/language/issues/1360 for a feature request to separate those imports.
Closing this, the import_path
package should hopefully be enough to help users figure out the full import path to library which can't be imported.
The Issue
While compiling a Web project that have some dependency or code like
dart:io
(or any non browser compatible dependency), build will show a warning:After this warning is IMPOSSIBLE to correctly investigate what transitive dependency is responsible for that.
If some developer wrongly imports
dart:io
, you won't find it! Onlygit
can help you, to find the changed line.If this happens in a 3rd part code you are totally lost (imagine a package that you just upgraded).
For me this is a SEVERE issue, since you are in dead zone and can't make any progress.
Also future builds won't show the warning message, only shows a normal start of
webdev serve
:Looks like a normal start of a
webdev serve
, but you won't find anything athttp://0.0.0.0:8080
, only a 404 response.Note that even restarting
webdev
process, it won't inform a skippedentrypoint
. The only possible way is to force rebuild, removing directory.dart_tool
and performing againpub get
.So, to fix it, you need to be in a paranoid mode, to try to remove
.dart_tool
, executepub dev
and than startwebdev serve
again to understand what is happening.Sugested Fix
Show in the warning the exactly dependency with problems.
If possible, show the line that imports this dependency, specially if the line is in the current project/package.
webdev serve
using cached builds, needs to show, again, the warning, informing a skipped entrypoint.An extra suggestion is a command
pub get -clean
and awebdev build/serve -clean
(you got the idea). Many build frameworks in the past, have theclean
option, to ensure that caches are being removed (for decades this saved many developers).Environment
Dart VM version: 2.8.3 (stable) (Tue May 26 18:39:38 2020 +0200) on "macos_x64"
build_runner 1.10.0