stefanpenner / ember-cli-addon-aware-resolver

ember-cli-addon-aware-resolver

Resolve paths within dependent packages, with additional awareness of:

• ember apps
• ember in-repo addons
• the pre-embroider (v1) ember addon format

Installation

yard add ember-cli-addon-aware-resolver

Usage

const resolveCliAware = require('ember-cli-addon-aware-resolver');

resolveCliAware('../foo', {
  basedir: '/some/absolute/path'
}) // => /some/absolute/foo


// for an ember app at /some/absolute/path
resolveCliAware('my-ember-app-name/foo', {
  basedir: '/some/absolute/path'
}) // => /some/absolute/path/app/foo



// with a v1 ember-addon configured as follows
{
  "ember-addon": {
    paths: ["./lib/my-in-repo-addon"]
  }
}

resolveCliAware('my-in-repo-addon/some/path/in/addon', {
  basedir: '/some/absolute/path'
}) // => /some/absolute/path/lib/my-in-repo-addon/addon/some/path/in/addon


resolveCliAware('my-dependency/some/path', {
  basedir: '/path/to/project/some/nested/path',

  // you can optionally pass pkg and pkgRoot for resolving package dependencies
  // if these are absent, package.json will be found by walking up the tree
  // from basedir
  pkg: myAlreadyReadPackageJson,
  pkgRoot: '/path/to/project'
}) // => /some/absolute/foo

try {
  resolveCliAware('non-existant-package', {
    basedir: '/some/absolute/path'
  });
} catch (e) {
  e.code // => "MODULE_NOT_FOUND"
}

Limitations

• Non-ember npm dependencies are not supported. It is assumed all resolutions one of:

  • classic ember apps
  • classic ember addons
  • v2 ember addons

• No support for app namespace merging: so files in an addon's app directory will not be resolved. Similarly, ${my-addon}/test-support will not be resolved as being merged to ${my-app}/tests.

• No support for path conflict resolution. This is unlikely to affect anybody, but if you have an Ember app with my-app/app/tests/foo, my-app/tests/foo will not resolve to this file, but instead only look for my-app/tests/foo

• No support for customized this.treePaths in addons.

• "main" imports are not supported (i.e. imports without paths)

ember-cli-addon-aware-resolver's Issues

Add support for peer dependencies

Peer dependencies are installed by default in npm@7 and so are usable again.

• Update node-fixturify-project to support peer deps
• check peer-dependencies for addons
• dep > dev dep > peer dep for root
• ignore dev dep for addon
• dep > peer dep for addon

Add Support for Non-Ember Dependencies

see #7

We only support:

• classic ember apps
• classic ember addons
• v2 ember addons

We assume a non-addon must be a classic ember app. In order to support "embroider v2" style apps, or non-ember dependencies, we would need a reliable way of detecting whether something is a classic ember app or a "standard" npm dependency.

Options:

• Assume everything is a standard npm dependency and accept another argument to indicate which is the classic ember app. This is possible because we don't expect there to be more than 1 classic ember app beyond the truly pathological cases (e.g. an addon depending on an app).
• Add something to package.json to identify that something is a classic ember app (ember-app keyword or similar)

Add Support for main imports

require('my-package')

should resolve to the main import (per my-package's package.json), or index.js if no main is specified

Add Support for Path Conflict Resolution

see #7

Given apps

my-app/
  app/
    tests/
      foo.js


my-pathological-app/
  app/
    tests/
      bar.js
  tests/
    bar.js

The following

resolve('my-app/tests/foo.js', options) === `${pathToMyApp}/app/tests.foo.js`)

will not work as we assume tests/foo.js must be in tests

Similarly resolve('my-pathological-app/tests/foo.js', options) is ambiguous and probably requires the ember env to properly disambiguate.