In ember-cli (for a very very long time) it has been possible to have ember-cli use a different main entry point for the addon than what a normal require('my-package-name') would return.
The way to do this is to add an "ember-addon": { "main": "some-other-file.js" } to your package.json. Normal require invocation will look at the main entry point, and ember-cli will look at some-other-file.js.
One nice benefit of this is that if you make main be addon/index.js and ember-addon.main be index.js, "normal" node_module resolution rules apply for things in addon/index.js. This means that things like eslint-plugin-import and TypeScript can actual see and validate an import from the addon name (though not with nested paths).
For example, typescript (and eslint-plugin-import) would see that this is valid:
import Component from 'sparkles-component';
export default class extends Component {}
I think this should be a RFC and built into default addon blueprint, rather than teaching addon authors.
^^ For the making typescript happy part, this needs to be documented
In ember-cli (for a very very long time) it has been possible to have ember-cli use a different main entry point for the addon than what a normal
require('my-package-name')
would return.The way to do this is to add an
"ember-addon": { "main": "some-other-file.js" }
to yourpackage.json
. Normalrequire
invocation will look at themain
entry point, andember-cli
will look atsome-other-file.js
.One nice benefit of this is that if you make
main
beaddon/index.js
andember-addon.main
beindex.js
, "normal" node_module resolution rules apply for things inaddon/index.js
. This means that things likeeslint-plugin-import
andTypeScript
can actual see and validate an import from the addon name (though not with nested paths).For example, typescript (and eslint-plugin-import) would see that this is valid:
See https://github.com/rwjblue/sparkles-component/pull/23 as an example.