New rule: `no-relative-packages` by panrafal · Pull Request #966 · import-js/eslint-plugin-import

panrafal · 2017-11-02T21:48:52Z

no-relative-packages

Use this rule to prevent importing packages through relative paths.

It's useful in Yarn/Lerna workspaces, were it's possible to import a sibling
package using ../package relative path, while direct package is the correct one.

Examples

Given the following folder structure:

my-project
├── packages
│   ├── foo
│   │   ├── index.js
│   │   └── package.json
│   └── bar
│       ├── index.js
│       └── package.json
└── entry.js

And the .eslintrc file:

{
  ...
  "rules": {
    "import/no-relative-packages": "error"
  }
}

The following patterns are considered problems:

/**
 *  in my-project/packages/foo.js
 */

import bar from '../bar'; // Import sibling package using relative path
import entry from '../../entry.js'; // Import from parent package using relative path

/**
 *  in my-project/entry.js
 */

import bar from './packages/bar'; // Import child package using relative path

The following patterns are NOT considered problems:

/**
 *  in my-project/packages/foo.js
 */

import bar from 'bar'; // Import sibling package using package name

/**
 *  in my-project/entry.js
 */

import bar from 'bar'; // Import sibling package using package name

Use this rule to prevent importing packages through relative paths. It's useful in Yarn/Lerna workspaces, were it's possible to import a sibling package using `../package` relative path, while direct `package` is the correct one. Co-authored-by: Rafal Lindemann <rl@stamina.pl> Co-authored-by: Tom Payne <tom@tompayne.dev> Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb

While I love this use case, I don't think this is the proper way to configure it. What if the foo package had a "src" dir, and a file inside it wanted to require('../')?

I think perhaps a better way to configure a rule like this is that the user would provide a list of paths (globs would be supported), and those paths would be considered boundaries - also called "jails".

So, for your example structure:

"rules": {
  "import/package-boundaries": ["error", {
    "boundaries": ["packages/*"]
  }],
}

That would overlap nicely with lerna/yarn workspaces package settings, and could allow for any imports or requires within a boundary, but nothing could escape the boundary from within.

panrafal · 2017-11-04T09:44:12Z

@ljharb I would say it's an idea for another rule.

Here, it's not forbidden to use ../ from src, because both 'src' and 'src/..' live in the same package. My proposal detects only, when package boundaries are crossed with relative paths.

What it does, it verifies to which packages both modules (importer and importee) belong. If the package is different - an error is raised. So as long as you stay within same package, you can have any relative paths.

On additional note, with this setup it's possible to make a simple autofix.

ljharb · 2017-11-04T17:42:24Z

How does your rule - since it has no configuration - know what a package boundary is?

One use case that some people have is nested package.jsons within the same project; would that conflict with this rule?

panrafal · 2017-11-05T00:12:47Z

Every package.json file with a name field defines a package for it's subdirectories, until another package.json defines another one. This is how node_modules, or yarn workspaces work.

With this directory structure:

node_modules
- foo
  - package.json ({"name": "foo"})
packages
- bar
  - node_modules
    - baz
      - package.json ({"name": "baz"})
  - package.json ({"name": "bar"})
src
package.json ({"name": "root"})

/node_modules/foo is a boundary of package "foo"
/packages/bar is a boundary of package "bar"
/packages/bar/node_modules/baz is a boundary of package "baz"
Anything else from the root directory is a "root" package

Importing ../../src from packages/bar is an error, because you're trying to import part of the root package from bar.
Importing ./node_modules/baz from packages/bar is also an error, because you're trying to import part of baz package from bar.

Both are unsafe because:

bar package uses parts of other packages, but don't have to define them in it's dependencies (no-extraneous-dependencies wouldn't catch it)
baz package may be hoisted by yarn to a top-level node_modules, which invalidates the relative paths

We're using this rule successfully on our yarn monorepo.

ljharb

Gotcha, thanks for clarifying.

This should be useful for normal single-package repos also, since they could just as easily require out of their own directory.

gotbahn · 2018-03-18T17:31:31Z

Looks nice, would love to use it. But PR looks abandoned. Any updates on that?

ljharb · 2018-03-20T13:25:53Z

It's not abandoned; it just needs review from other maintainers, after which I'll rebase and merge it.

omasback · 2018-03-30T23:04:17Z

I don't really understand everything in this thread but I was wishing there was a rule to limit the depth of relative paths. like ./ would be ok but ../ and ../../ would not. You could configure the allowed depth. I'm just dealing with a project with a lot of dots and slashes when root-relative paths would be much easier to read. Anyways, just my 2c!

orm109 · 2018-06-21T11:12:48Z

any update with this PR ?

niieani · 2019-03-21T16:47:07Z

Anything we can do to get this merged?

fernandopasik · 2019-08-09T14:35:27Z

@benmosher could you help with this one? :D

teoxoy · 2020-01-08T05:27:38Z

Can I do anything to get this merged? - I find this new rule really useful for monorepos

ljharb · 2020-06-07T06:09:11Z

@panrafal I've rebased this, but there seems to be a test failing.

coveralls · 2020-06-07T06:34:07Z