Solidity Tutorial: All About Imports | by Jean Cvllr | Mar, 2022

Photo by Tim Schmidbauer on Unsplash
Modules and Code Modularity.Solidity Imports.Types of Solidity Import Syntax.
* Global Import
* Specific Imports
Import Aliases.
* Global Alias
* Alias Specific
Which import syntax to use?What can you import from a Solidity file?Solidity Import Syntax Cheatsheet
  • Creating reusable pieces that other files can import.
  • Making it easier to understand and digest the entire Solidity codebase of your project.
  • Making it easier to work with the “Solidity modules” by focusing on smaller files (useful when debugging).
import “./MySolidityFile.sol”;

Global Imports

import “./MySolidityFile.sol”;
  1. All global symbols (what I call “Solidity Objects) defined in “./MySolidityFile.sol” get imported into the current global scope.
  2. All global symbols imported inside “./MySolidityFile.sol” get also imported into the current global scope.

“This form is not recommended for use because it unpredictably pollutes the namespace.”

If you add new top-level items inside “filename”, they automatically appear in all files that import like this from “filename”.

Specific Imports

Import { Something } from “./MySolidityFile.sol”;

“only import what you need”

  • Aliases for global imports: can then be used to refer to specific objects defined in the file, using the dot “.” syntax (like object properties).
  • Aliases for specific imports: enable to rename objects or symbols imported from a Solidity file, for instance, to avoid naming collision (or to give a better name for better code clarity if needed).

Global Aliases

// longer syntax
import * as Endpoints from “./Endpoints.sol”.
// shorter syntax
import “./Endpoints.sol” as Endpoints;

Specific Aliases

import { Point as Coordinate, GPS } from “./Endpoints.sol”;
  • Avoid naming collisions: in cases where what you want to import is already imported by other files. If you encounter naming collisions while importing, use aliases to solve this.
  • Prevent unexpected behavior (if the compiler did not flag it, and a variable you are using references to the wrong variable imported from elsewhere).
  • Rename what you are importing: if you want to use more meaningful names in your context and for your code clarity.

“On the principle that clearer code is better code, you should import the things you want to use in a module.”

“Wildcard imports (from import *) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools.”


  • Runs the risk of confusing the maintainers and users of Solidity contract or library.
  • Reduces code readability. Developers using your Solidity contracts or library can have difficulty knowing where the imported names come from.

Bugs related to namespace

  • Importing everything clutters the local “namespace”, making debugging more difficult.
  • Imported names can change when you update your dependencies. Therefore, a wildcard import that works today might be broken tomorrow.
  • contract
  • library
  • interface
  • enum (defined at the file level)
  • struct (defined at the file level)
  • error definitions (defined at the file level)
  • functions (defined at the file level, since Solidity 0.7.1)
  • User-defined Value Types (since their introduction in Solidity 0.8.8)
import "./modules/MySolidityFile.sol";
import * as mySolidityModule from "./modules/MySolidityFile.sol";
import "./modules/MySolidityFile.sol" as mySolidityModule;
import { MyContract } from "./modules/MySolidityFile.sol";
import { 
} from "./modules/MySolidityFile.sol";
import { 
reallyReallyLongSolidityModuleExportName as solidityModule
} from "./modules/MySolidityFile.sol";
import {
reallyReallyLongSolidityModuleExportName as solidityModule,
anotherLongSolidityStructName as MyStruct
} from "/modules/my-module.js";

Leave a Comment