I just put some of my code from a/b.dart to a/b1.dart file and now I started getting lot of errors on importing.
Is there any command or any other fix to import all a/b1.dart file in these files instead of manually opening each file and importing one by one.
I understand that a function or a property can be defined in more than two files and Dart can't make the right choice but if a function or property is defined in just one place, I think there must be some way to import it except searching for a/b.dart and replacing it with a/b.dart + a/b1.dart and then optimizing all imports.
As much as I am aware, Plugins/Extensions for your specific IDE (for dart) can be found that will help you with this problem.
I would recommend using dartdev tools - dartfix
In Flutter, for importing libraries within our own package's lib directory, should we use relative imports
import 'foo.dart'
or package import?
import 'package:my_app/lib/src/foo.dart'
Dart guidelines advocate to use relative imports :
PREFER relative paths when importing libraries within your own package’s lib directory.
whereas Provider package says to always use packages imports :
Always use package imports. Ex: import 'package:my_app/my_code.dart';
Is there a difference other than conciseness? Why would packages imports would reduce errors over relative imports?
From the same Dart guidelines, further down they give this reason for the relative imports:
There is no profound reason to prefer the former—it’s just shorter, and we want to be consistent.
Personally, I prefer the absolute method, despite it being more verbose, as it means when I'm importing from different dart files (in other folders), I don't have to work out where the file to be imported is, relative to the current file. Made-up example:
I have two dart files, at different folder levels, that need to import themes/style.dart:
One is widgets/animation/box_anim.dart, where the relative path import would be:
import '../../themes/style.dart';
The other is screens/home_screen.dart with the relative import:
import '../themes/style.dart';
This can get confusing, so I find it better to just use the absolute in both files, keeping it consistent:
import 'package:myapp/themes/style.dart';
And just stick that rule throughout. So, basically, whatever method you use - Consistency is key!
The Linter for Dart package, also has something to say about this, but is more about the Don'ts of mixing in the '/lib' folder:
DO avoid relative imports for files in lib/.
When mixing relative and absolute imports it's possible to create
confusion where the same member gets imported in two different ways.
An easy way to avoid that is to ensure you have no relative imports
that include lib/ in their paths.
TLDR; Choose the one you prefer, note that prefer_relative_imports is recommended in official Effective Dart guide
First of all, as mentioned in this answer, Provider do not recommands package imports anymore.
Dart linter provides a list of rules, including some predefined rulesets :
pedantic for rules enforced internally at Google
lints or even flutter_lints (previously effective_dart) for rules corresponding to the Effective Dart style guide
flutter for rules used in flutter analyze
Imports rules
There is actually more than two opposites rules concerning imports :
avoid_relative_lib_imports, enabled in pedantic and lints rulesets, basically recommend to avoid imports that have 'lib' in their paths.
The two following are the one you mention :
prefer_relative_imports, enabled in no predefined rulesets, but recommended in Effective Dart guide in opposition to :
always_use_package_imports, enabled in no predefined rulesets. Which means that it is up to you and to your preferences to enable it (be careful, it is incompatible with the previous rule)
Which one should I choose?
Choose the rule you want ! It will not cause any performance issue, and no rule would reduce errors over the other. Just pick one and make your imports consistent across all your project, thanks to Dart linter.
I personnaly prefer using prefer_relative_imports, as it is recommended by Dart team, with this VSCode extension which automatically fix and sort my imports.
Provider do not need packages imports anymore.
This was a workaround to an old Dart bug: Flutter: Retrieving top-level state from child returns null
TL;DR, by mixing relative and absolute imports, sometimes Dart created a duplicate of the class definition.
This led to the absurd line that is:
import 'package:myApp/test.dart' as absolute;
import './test.dart' as relative;
void main() {
print(relative.Test().runtimeType == absolute.Test().runtimeType); // false
}
Since provider relies on runtimeType to resolve objects, then this bug made provider unable to obtain an object in some situations.
My 5 cents on the topic are that absolute (package:my_app/etc/etc2...) imports cause much less trouble than relative ones (../../etc/etc2...) when you decide to reorganize/cleanup your project`s structure because whenever you move a file from one directory to another you change the "starting point" of every relative import that this file uses thus breaking all the relative imports inside the moved file...
I'd personally always prefer absolute to relative paths for this reason
This question already has good answers, but I wanted to mention an insanely annoying and hard-to-find problem I experienced with unit testing that was caused by a relative import.
The expect fail indicator for an exception-catching expect block
expect(
() => myFunction,
throwsA(isA<InvalidUserDataException>())
);
was showing the actual result as exactly the same as the expected result, and zero indication of why it's failing.
After massive trial-and-error, the issue was because the expected InvalidUserDataException (a custom-made class) was being imported to the test file in RELATIVE format vs PACKAGE format.
To find this, I had to compare side-by-side, line-by-line, call-by-call between this test file and another test file that uses the exact same exception expecters (It's lucky, we had this), and just by chance, I happened to scroll to the top of this file's imports and see the blue underline saying prefer relative imports to /lib directory.
No, they're not preferred; they're necessary, because the moment I changed that to a PACKAGE (absolute) import, everything suddenly started working.
What I learned from this is: Use absolute imports for test files (files outside the lib directory)
e.g. inside of src/test/main_test.dart
DON'T: use import '../lib/main.dart'
DO: use package:my_flutter_app/main.dart
Maybe other people knew this already, but I didn't, and I couldn't find anything online with searches about this issue, so I thought I would share my experience that might help others who got stuck around this.
Does anyone know why this happens?
Edit: For context, this happened while using Flutter 2.1.4 (stable) with Sound Null Safety
Do you use Integration Tests?
If the answer is yes, then in most cases you need to use package imports. When you attempt to run your integration tests on a physical device, any relative imports will not be able to find what they're looking for.
Example: https://github.com/fluttercommunity/get_it/issues/76
You can enforce package imports in your project by using these two linting rules:
always_use_package_imports
avoid_relative_lib_imports
I also prefer package imports because they stick even when rearranging your files and folders. Relative imports frequently break and it's a pain to have to remove them and reimport the offending dependency.
One very simple reason to not use package imports: rename your package without editing every dart file
Renaming can happen a few times while the product does not have a definitive name, and you or your product owner decides to change it.
It is much more painful to rename with package imports as your package name is in every import.
Of course you can change it with a find/replace query, but it's a useless edit on every dart file you can avoid with relative imports.
Plus, vscode allows to automatically update relative imports on file move/rename and I have never had any issue with this feature.
I've already Google'd for an answer, since this is a common problem, but all the replies point in using alternatives instead of explaining why this doesn't work, so I'm asking here.
I put this code in my Atom's init.coffee script:
beautify = require('js-beautify').html
But Atom fails with Failed to load init.coffee and Cannot find module 'js-beautify'. Curiously enough, this works on a package and this works if I type the exact same code on Atom's console.
Of course, I could write a package for this, in fact there are a couple available, this is just an example because I want to learn how to require modules from init.coffee for future tweaks.
Thanks a lot!
When you require() from init.coffee, Atom looks for those modules in its own path. An example of where you might want to do that is if you had oni = require('oniguruma') to get access to regular expression functions.
In order to get to js-beautify, you have to specify its complete path. So far, only explicitly declaring the entire absolute path has worked for me:
beaut = require 'C:\\Users\\<username>\\.atom\\packages\\atom-beautify\\node_modules\\js-beautify'
console.log beaut
In practice, the most reliable way to use a module like this is to globally install it so that you can link to your global NPM folder. Linking to a module inside a package will break if the package is ever uninstalled.
I may not fully understand the wiki article on scoping, so forgive me if this sounds dumb.
Intro:
I have a solution (ABC.sln) with over 40 projects and am trying to implement OpenWrap for package management.
So I did the following in the solution's root folder:
o init-wrap -all
That worked fine: I now have a file called SLN.wrapdesc in the solution's root folder. All of the .csproj files in the subfolders contain the OpenWrap targets line.
I then proceded to add the different wraps to the solution with:
o add-wrap -Name xxx
Again, this worked fine: I have some wraps in the wraps folder, and the build doesn't break after removing the old references from the projects.
Problem:
All of the contents of the wraps are going to all of the projects, even for those that don't need it. I would like to be able to specify which wraps go where, eg AjaxControlToolkit only goes into web projects.
What I tried
First, I removed the AjaxControlToolkit from the wrapdesc:
o remove-wrap AjaxControlToolkit
This causes the build to break (as expected). Then I tried the following:
1. Try to add the wrap back with a scope:
o add-wrap -Name AjaxControlToolkit -scope webproject
This simply puts the wrap back in the wraps folder. I then added <OpenWrap-Scope>customscope</OpenWrap-Scope> to the project file, but the build still broke.
2. Try and manually add a file called ABC.webproject.wrapdesc to the root folder. This causes the following error when I try to open the solution:
The "exists" function only accepts a scalar value, but its argument "#(_WrapFile->'%(FullPath)')" evaluates to "D:\Projects\ABC.webproject.wrapdesc;D:\Projects\ABC.wrapdesc" which is not a scalar value.
I guess it doesn't like 2 wrapdesc files. That is strange because the wiki says "...you can add a second descriptor alongside your default descriptor..."
So now I'm stuck. Anyone have any ideas?
The per-msbuild file is really not a recommended approach to managing dependencies. Doing it per project is not quite the design philosophy behind OpenWrap, so the system is not quite optimized for those scenarios.
If you don't need something from those assemblies then the easiest way to solve it is to not use the references by not using any code from those packages. This solves the problem very easily as nothing will get loaded (or even need to be on disk) if no code has been added to it.
That said, add-wrap -scope newscope will create an additional .wrapdesc file that will add the new dependency to the new scope, by creating a myProject.newscope.wrapdesc file independently of the original myProject.wrapdesc.
If you do want to do this per-project, have you tried using the convention-based scoping? Something like:
directory-structure: src\*{scope: Web=WebProjects}*
Would take any project in a folder child of src containing Web in the name and assign those to the WebProjects scope.
I know that one has worked fine for my projects so far, although you do have to restart VS as it aggressively caches certain files and will not see the change.
Customizing the msbuild file itself is not fully tested (and the wiki entry was very much a design spec rather than final documentation, not all of it has been built that way) so it may or may not work. Happy to take a look if you can open a bug ticket on http://github.com/openrasta/openwrap/issues
Summary :
I have a project using GNU Autotools. I have a pot file. I need to update it. Is there a magical "make" task that run xgettext for me (I'm lazy ?)
Verbose version :
Hi
I am trying to setup a project using GNU autotools and gettext.
I'm trying to follow the 'lazy' path (that is, only writing configure.ac, Makefile.am, and such, and let tools generate the rest for me as much as possible).
I used gettextize once on my package, so I got a package.pot file created, and I derived a fr.po file (I'm trying to translate in french).
I never managed to get my code translated, but I figured out it might be because the code was not in the proper place. The translated string is in a lib instead of a main, and the documentation is quite unclear about what I must do in this case. If my main call a function in a lib, and the function from the lib is using _(). Should I use gettext of dgettext in this case ? My lib is just here for organisation purpose, so I'm okay with using the same domain (only one package.pot file for the whole app).
So, to try something simpler, I moved my string to the main (it's really just a hello world, for the moment). So I need to update the package.pot file, at least, to realize that the string position changed, need I ? In this case, would I use xgettext manually (painfully passing it the list of all interesting cpp files, which will be a pain in the ass when I have more than one file), or is there a 'make whatever' task somewhere that I can run ?
This may look stupid, but I've not been able to find it.
Also, any help on finding why my code is not translated, (anything not in http://www.gnu.org/software/gettext/FAQ.html#integrating_noop) is welcome !
Thanks
PH
Ok, it turns out that :
there is a update-po task in the generated Makefile of the po/ folder, that does just what I want ;
this tasks looks to file referenced in the POTFILES.in file, which I had forgotten to update.
So it was something stupid.