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.
Probably a basic mistake, but the cause is eluding me. I am trying to import a package, but I get an error saying it cannot be found or imported.
First I set the current directory to the parent directory of the package, and this does not work.
Second, the docs say that the parent folder of the package must be added to the matlab path. I tried this, and still no luck.
It is not due to using plot as the package name as I get the same error when trying to import analysis.
What I can do is to import using: import plot.* or import analyse.* and then go on to use the functions in the packages, but I want to use the namespaces (i.e. not use .*).
Edit
I'm having this problem on both versions I have installed: 2015b and 2016a.
The answer is that, somewhat counterintuitively, you don't need to call import at all. The docs state that
The parent of the top-level package folder must be on the MATLAB path.
Which is what your addpath(pwd) does and then state that (emphasis is mine):
All references to packages, functions, and classes in the package must
use the package name prefix, unless you import the package.
Meaning at this stage you should be able to call
analyse.testFunc
If you were to import analyse.testFunc you would then be able to call testFunc without prefacing it with the namespace but since you want to retain the namespace the answer is to not call import at all.
I want to clean my code structure and put class/object files in another directories in my gatling project.
If i put all simulation class and utils class in the same directory and same package i do not need an import statement and everything works fine.
Let's say my structure is as follow :
/user-files
----/simulations
--------MySimulation.scala
----/utils
--------Router.scala
I have tried several import or naming configuration to be able to use Router in my Simulation.
Follow package naming as directories structure
Put simulations and utils class in the same package
I have also tried different style of import
//using package
import packagename.Router
//another try
import packagename.Router._
//without package name
import Router._
My attempt to search a solution on scala docs or stack overflow didn't helped me.
This is the error given after executing gatling.bat
not found: value Router
You can't do that this way: there's one single source folder, which is by default /user-files/simulations.
If you want to use folders/packages (which is a good thing), you can have a structure such as:
/user-files
----/simulations
--------MySimulation.scala
--------/utils
------------Router.scala
Then, in Scala, packages and folder hierarchy are not related, BUT it's a good practice to use the same convention as in Java.
So, you would have:
package utils
object Router
then in MySimulation:
import utils.Router
Please tell me a more describing title :P
I have an SBT project in IntelliJ and its src directory constructed like:
src/main/scala/package1/AAA.scala
src/main/scala/package1/BBB.scala
src/main/scala/package2/CCC.scala
src/main/scala/...
So now these classes are imported like:
import package1.AAA._
But actually I want to import these classes like:
import org.myname.package1.AAA._
At the moment I have two ways; one is to put org.myname to all the class files' package attributes like:
package org.myname.package1
class AAA {...
which works, but doing this manually is time consuming, and makes things complicated.
Another one is to reformat the directories like:
src/main/scala/org/myname/package1/AAA.scala
src/main/scala/org/myname/package1/BBB.scala
src/main/scala/org/myname/package2/CCC.scala
src/main/scala/org/myname/...
which works too, but I'd not like to make the looking of the structure like this.
Is there an automatic way to include all classes into org.myname without changing the structure, with the SBT or IntelliJ features?
Create a new package named org.myname.
Move the package1 inside org.myname
Move package2 inside org.myname
IntellIJ IDEA will fix everything for you.
I'd like to import package com.example.abc from com.example.iop in similar manner to bash expression ../abc.
Is this possible in Scala? I've read couple of articles but they say nothing about my case.
Update: I've discovered code suitable for simple uses (I've seen it in some project while ago):
package com.example
package com.example.abc
import iop
Your updated package structure has a hint of the solution, but isn't quite right. You can live in multiple packages, including a broad parent package defined by the first package statement – subsequent statements refine the tree.
package com.foo // we're in: com.foo
package bar // we're also in: com.foo.bar
package wibble // we're also in: com.foo.bar.wibble
import frobble._ // this could be com.foo.frobble or com.foo.bar.frobble or com.foo.bar.wibble.frobble
Obviously, things can get confusing if you have multiple packages with the same name, but the compiler asks you politely to sort that out.
That is simply not possible -- same as in Java.