Shorten Es2015 Import Paths

I am working on a large ES2015 project that has a lot of import statements referring to a library in a deep directory structure. Currently, imports take the form of import Status

Solution 1:

You can also use resolve.alias to handle roots that might move around:

resolve: {
  alias: {
    importName: 'actual/path/here',
    '__another_alias__': 'another/path'
  }
}

Which you could then use as:

import someImport from'importName';
import anotherImport from'__another_alias__/sub/path';

Solution 2:

One common pattern is to have a single file that imports all the components of a similar context and then exports them all. Then you can import from this single file at a much higher level in the tree. For example, Angular2 does this.

/**
 * @module
 * @description
 * Starting point to import all public core APIs.
 */export * from'./src/core/metadata';
export * from'./src/core/util';
export * from'./src/core/prod_mode';
export * from'./src/core/di';
export * from'./src/facade/facade';
export {enableProdMode} from'angular2/src/facade/lang';
export {
  createPlatform,
  assertPlatform,
  disposePlatform,
  getPlatform,
  coreBootstrap,
  coreLoadAndBootstrap,
  createNgZone,
  PlatformRef,
  ApplicationRef
} from'./src/core/application_ref';
export {
  APP_ID,
  APP_INITIALIZER,
  PACKAGE_ROOT_URL,
  PLATFORM_INITIALIZER
} from'./src/core/application_tokens';
export * from'./src/core/zone';
export * from'./src/core/render';
export * from'./src/core/linker';
export {DebugElement, DebugNode, asNativeElements} from'./src/core/debug/debug_node';
export * from'./src/core/testability/testability';
export * from'./src/core/change_detection';
export * from'./src/core/platform_directives_and_pipes';
export * from'./src/core/platform_common_providers';
export * from'./src/core/application_common_providers';
export * from'./src/core/reflection/reflection';

As you can see, rather than having to import {Foo} from './src/core/platform_common_providers' for example you simply do import {Foo} from "angular2/core"

Solution 3:

Another possibility is Babel's resolveModuleSource option, but note that it can only be configured programatically, not via .babelrc, and is only going to apply to module syntax compiled by Babel. So for example if you need to reference the lib from code that's not module syntax compiled by Babel, that might favor doing it via the bundler (Webpack) or by putting the lib in node_modules (it doesn't matter that you're not publishing it to npm) as others have suggested in the comments.

Note that if you do it via the bundler, that'll only work in the bundled output, not for running the code in Node directly / using Babel's require hook. So consider for example how you'll test this code. Are you going to bundle the tests? It's possible you may want to use several of these options in combination or in different contexts.