sindresorhus / import-local

Let a globally installed package use a locally installed version of itself if available

import-local

Let a globally installed package use a locally installed version of itself if available

Useful for CLI tools that want to defer to the user's locally installed version when available, but still work if it's not installed locally. For example, AVA and XO uses this method.

Install

npm install import-local

Usage

import importLocal from 'import-local';

if (importLocal(import.meta.url)) {
	console.log('Using local version of this package');
} else {
	// Code for both global and local version here…
}

You can also pass in __filename when used in a CommonJS context.

---

Get professional support for this package with a Tidelift subscription
_{Tidelift helps make open source sustainable for maintainers while giving companies
assurances about security, maintenance, and licensing for their dependencies.}

import-local's Issues

import-local doesn't play well with yarn aliases

If I have two copies of a dependency some-pkg installed in my project's local node_modules, but one is installed under a different name using a Yarn alias, import-local should noop in the aliased package. Instead, calling import-local in the aliased package actually resolves to the other local installation of the package.

Repro and failing test case is here: master...mxmul:yarn_alias_repo

Let me know if there's anything else I can do to help resolve :)

importLocal(__filename) returning an empty object, leading to local install which does not exist and skipping all ava tests

hi Sindre, maintainers and everybody else,

I would like to report a very strange issue and I hope you'll be able to shine some light on it.

I found that my ava, installed as a devdependency, was doing nothing, just silently exiting without an error. I placed some console.logs in the files in node_modules and it lead to this package, import-local — specifically, require(localFile) was returning an empty plain object:

return !filenameInLocalNodeModules && localFile && require(localFile);

now true + true + {} = empty plain object {} and it's truthy, which caused line if (importLocal(__filename)) to just do nothing:

if (importLocal(__filename)) {
	console.log('Using local version of this package');
} else {
	// Code for both global and local version here…
}

There was no globally installed package (ava) but importLocal above was returning truthy empty object and there was nowhere to run the tests on.

Do you have a clue what is going on?

By the way, if I clone this repo, npm i and run tests, they fail the "global" test:

What's also strange, my GItLab CI also has this issue and this morning ava unit tests seem to have silently skipped on the CI. That's Linux on a clean slate so something really strange is going on.

Maybe we should add more checks, for example, does importLocal(__filename) result object have keys (if it's an object)?

Thank you.

import-local not work for windows when gloab module and local module in different drive

As mentioned in the title, in this line:
const filenameInLocalNodeModules = !path.relative(localNodeModules, filename).startsWith('..');
filenameInLocalNodeModules always true，because path.relative(localNodeModules, filename) always return filename. However, it is a absolute path and it does not start with “..”

import-local may not work correctly in a Yarn workspace

When using Yarn workspaces, such as in a monorepo setup, node_modules may be split across several locations like so:

- node_modules // workspace root
  - dep@v1
- app1
  - node_modules // nested projects
    - dep@v2
- lib1
  - node_modules

In this scenario an installed dependency may exist at the root node_modules or in one of the nested ones, depending on whether Yarn chooses to hoist it. The dependency may even exist in both places at different version numbers, as illustrated with dep above.

On this line, import-local effectively assumes that the directory it's running from is the sole local directory:

import-local/index.js

Line 10 in 101c451

const localFile = resolveCwd.silent(path.join(pkg.name, relativePath));

In a workspace however, import-local could be running from any of the node_modules folders. If for example import-local is installed at the workspace root and gets invoked by dep@v2, import-local will end up finding and invoking dep@v1, because that's in the same directory.

I would say this is a bug because neither version of dep was globally installed, and so I would expect import-local to return false-y.

can some explain me, i see the package.json doesnt have the type module inside, but i can import it without pack tool, how do it work