3 ms·

> Use Absolute Paths for Importing Code Blocks import { FormType } from '../../../../types/form'; import { DateType } from '../../../../types/date';

> Use Absolute Paths for Importing Code Blocks import { FormType } from '../../../../types/form'; import { DateType } from '../../../../types/date'; // This is considered bad practice Disagree on this one. Beauty of typescript is giving you auto-import autocompletion in your editor, and not having to worry about relative paths any more. I don't think I've manually written an import statement in years.

latchkey 4y ago
I think this can be generalized into "use the method that works best with automated tooling".
- madeofpalk 4y ago
  I think that's very fair, and great advice. We have a strong preference against eslint rules that don't have an auto-fix option.
Jochim 4y ago
Personally I'm a fan of using relative paths for anything in the same directory or a sub-directory of the current file and absolute paths for everything else. I feel like it keeps things clean while also providing a way to distinguish between closely related modules and imports from further away in your application.
- throwaway284534 4y ago
  I’ve also fallen back into favoring relative paths and doing my best to keep nested paths to a minimum. This also makes publishing on Deno’s module listing possible too!
bsimpson 4y ago
Using relative imports that ../ out of your package directory confuses TypeScript about which files are in-scope (and how to structure the resulting files). You can end up with weird shit like my-library/dist/my-library/index.js. (I'm sure you can configure your way out of this. That's a puzzle I haven't solved and don't intend to invest time into.) Yarn Berry has a node_modules mode now, which makes it behave like Yarn Classic and NPM. It also allows you to import sibling projects in a monorepo: "peerDependencies": { "my-library": "workspace:*", which means you can import { thing } from 'my-library' and have it work as expected, even when my-library is a sibling project in your monorepo.
015a 4y ago
All code is fast to write. Decisions like this should be optimized for reading and comprehension, not writing. IMO: Extreme opinions one way or the other don't work, and thus (most of the time) code-complete automation also doesn't work. import { User } from "./User"; # is probably the most readable and comprehensible way to write this. import { User } from "app/domain/users/types/User"; # is probably less comprehensible import { User } from "../User"; # may be ok, but it may also depend on how deep this directory is, because import { User } from "app/users"; # is actually pretty comprehensible The point should be to make it really quick for readers to understand where this code is coming from. Imagine a situation where you've got identically named imports; like a import { User } from "foo/db/types"; # used to schematize a user in the database import { User } from "foo/api/createUser/types"; # used to schematize a component of the request body for creating users Maybe the tokens themselves are named poorly, but look past that. Many people find a specific file using, simply, CMD+P (or your editor's equivalent). There's no context for where they may be at; which inherently makes relative imports less comprehensible. import { User } from "./User"; const u = new User(req.body.user); # but wait... what kind of user did I just create? There are many ways to help alleviate this low state of comprehension; and what should be deployed is difficult to create hard-and-fast rules around because its so domain specific. import { User } from "foo/api/createUser/types"; # having an import path like this can help, but maybe only in small files where the imports aren't 500 lines above where they're used. import { User as CreateUserAPIUser } from "./User"; # aliasing imports is a good solution import * as createUserApiTypes from "foo/api/createUser/types"; const u = new createUserApiTypes.User(req.body.user); # importing, then properly naming, the entire module is in my experience an underutilized tool to help with comprehension.
- lelandfe 4y ago
  > what kind of user did I just create? Do y’all look at the import path at the top of a file to understand a function on line 450? Any editor I can think of provides a way to show what you’re using here. I don’t think import path intelligibility should really be that high on the list of concerns. > (most of the time) code-complete automation also doesn't work They’re pretty great these days, in my experience.
optiomal_isgood 4y ago
If TypeScript and VSCode are configured properly, it will suggest an auto-import that uses the absolute paths. In my experience, it can be a bit inconsistent though and sometimes it goes for the relative paths instead.

latchkey 4y ago

I think this can be generalized into "use the method that works best with automated tooling".

madeofpalk 4y ago
I think that's very fair, and great advice. We have a strong preference against eslint rules that don't have an auto-fix option.

Jochim 4y ago

Personally I'm a fan of using relative paths for anything in the same directory or a sub-directory of the current file and absolute paths for everything else. I feel like it keeps things clean while also providing a way to distinguish between closely related modules and imports from further away in your application.

throwaway284534 4y ago
I’ve also fallen back into favoring relative paths and doing my best to keep nested paths to a minimum. This also makes publishing on Deno’s module listing possible too!

bsimpson 4y ago

Using relative imports that ../ out of your package directory confuses TypeScript about which files are in-scope (and how to structure the resulting files). You can end up with weird shit like my-library/dist/my-library/index.js. (I'm sure you can configure your way out of this. That's a puzzle I haven't solved and don't intend to invest time into.) Yarn Berry has a node_modules mode now, which makes it behave like Yarn Classic and NPM. It also allows you to import sibling projects in a monorepo: "peerDependencies": { "my-library": "workspace:*", which means you can import { thing } from 'my-library' and have it work as expected, even when my-library is a sibling project in your monorepo.

015a 4y ago

All code is fast to write. Decisions like this should be optimized for reading and comprehension, not writing. IMO: Extreme opinions one way or the other don't work, and thus (most of the time) code-complete automation also doesn't work. import { User } from "./User"; # is probably the most readable and comprehensible way to write this. import { User } from "app/domain/users/types/User"; # is probably less comprehensible import { User } from "../User"; # may be ok, but it may also depend on how deep this directory is, because import { User } from "app/users"; # is actually pretty comprehensible The point should be to make it really quick for readers to understand where this code is coming from. Imagine a situation where you've got identically named imports; like a import { User } from "foo/db/types"; # used to schematize a user in the database import { User } from "foo/api/createUser/types"; # used to schematize a component of the request body for creating users Maybe the tokens themselves are named poorly, but look past that. Many people find a specific file using, simply, CMD+P (or your editor's equivalent). There's no context for where they may be at; which inherently makes relative imports less comprehensible. import { User } from "./User"; const u = new User(req.body.user); # but wait... what kind of user did I just create? There are many ways to help alleviate this low state of comprehension; and what should be deployed is difficult to create hard-and-fast rules around because its so domain specific. import { User } from "foo/api/createUser/types"; # having an import path like this can help, but maybe only in small files where the imports aren't 500 lines above where they're used. import { User as CreateUserAPIUser } from "./User"; # aliasing imports is a good solution import * as createUserApiTypes from "foo/api/createUser/types"; const u = new createUserApiTypes.User(req.body.user); # importing, then properly naming, the entire module is in my experience an underutilized tool to help with comprehension.

lelandfe 4y ago
> what kind of user did I just create? Do y’all look at the import path at the top of a file to understand a function on line 450? Any editor I can think of provides a way to show what you’re using here. I don’t think import path intelligibility should really be that high on the list of concerns. > (most of the time) code-complete automation also doesn't work They’re pretty great these days, in my experience.

optiomal_isgood 4y ago

If TypeScript and VSCode are configured properly, it will suggest an auto-import that uses the absolute paths. In my experience, it can be a bit inconsistent though and sometimes it goes for the relative paths instead.