Is there any disadvantage to putting ES6 import statements at the bottom of code files?

Question

I only came across this practice recently while looking at Apollo Client examples - I didn't realize all import statements could be at the bottom of a .js file. This seems like a great idea because it's rare that on opening a file the import statements are what I'm looking primarily to deal with.

In cases where order does not matter, is there any disadvantage we should be aware of with this practice?

This may be an example-only practice since the same company puts imports at the top in production code - but I'm not sure why it couldn't apply to production code. We're using TypeScript but I believe the concerns are the same with vanilla ES6.

Arkose

A disadvantage is readability, I guess. Typically you want to define your functions before they are called, although with function hoisting in JS it doesn't matter, but it is still considered good practice to do so. – Fretwork

One of the major disadvantage is readability, And as soon as you use any module bundler, It will throw error and it will ask you to reorder all import statements to the top which makes more sense. – Siloam

it's rare that on opening a file the import statements are what I'm looking primarily to deal with - you can easily fold them in IDE. On the other hand, a lot of people may want to know what are the things they deal with in current file. And voila, seemingly dependency-free module contains a bunch of imports in the place where nobody expects them. What a brilliant way to peeve fellow developers. Works best with omitted semicolons, brackets and 1 == val conditions. – Bernardinebernardo

@estus Yeah, "it's a nonstandard convention" as a downside. – Arkose

@estus IDE folding would be a good alternative, don't have it in VS Code yet. – Arkose

VS Code is more of an editor rather than IDE. At least Webstorm/Phpstorm had it for quite a while. – Bernardinebernardo

Answer 1

Normally, you'd want to declare/define something first, then use it. Using it first and then defining it seems weird. Someone reading your code would expect the imports to be at the top of the file.

This is also true for functions: you could use them before you declare them, but someone who reads the code would expect to find the declaration of the function a few lines above, not below:

var result = add(10, 5);

// some other code

function add (a, b) {
  return a + b;
}

This seems like a great idea because it's rare that on opening a file the import statements are what I'm looking primarily to deal with.

I disagree. When I look at a file, I'm interested in its dependencies and its relation to other files in the project.

Let's say you want to understand what a certain file is about. Normally, you would glance through the code, first looking at the imports, then looking at the code that uses these imports. Otherwise, you would encounter a whole lot of things that you've never seen.

Doited

Agree when I'm looking at open source code and getting a handle on it, or navigating around very large project. Most of my use cases though are working with the same relatively small number of files on any given feature. – Arkose

Yes, that depends on your personal preference, but if you want others to be able to easily read and understand your code, I think you should put the import statements at the top of the file. – Doited

That's a fair point. Modernly when I want to know where something is defined I F12, so whether it's above or below is often irrelevant. Seems like it's far outside of convention at present though. Thanks for the thoughts! – Arkose

Answer 2

Putting imports at the end of a module is an AWESOME idea! 👍

I always put logic in front of the implementation details

export const result = add(10, 5);

function add (a, b) {
  return a + b;
}

because, when reading code, as well as writing tests - I want to know first WHAT it does, not HOW.

Putting imports at the end will greatly improve readability of my code 👍👍

ps. I use Parcel for bundling - and it processes such code without errors

Ingeminate

Your code example happens to work only because the add function is automatically hoisted because it's a named function. – Horseflesh