The addon's entry point, index.js is key here.
The addon exposes several hooks during addon/app build-time, several of which are treeForX where X is some part of the app/addon. In our case, depending on the addon type, we hook into one or more of theese hooks, at which point, we restructure and rename the files on the fly, so they're conventionally placed and named by the time the parent app tries to load them.
treeForAppmovescomponent.jstoapp/components/addonName.jstreeForTemplatemovestemplate.hbstoapp/templates/components/addonName.hbstreeForAddonmovesstyle.csstoaddon/styles/addonName.css- Optionally, we could also add a compile step from
.scsshere. I verified it and it works, but I wanted to keep things light for now. - Moving it to
app/styles/addonName.csswould also work, but this way, the resulting.cssends up invendor.cssand this would make it end up inappName.css
- Optionally, we could also add a compile step from
treeForAppmoveslibrary.jstoapp/lib/addonName.js
treeForAppmoveshelper.jstoapp/helpers/addonName.js
It's just basic node file/folder manipulation. I'm using the fs-extra library, which makes automatic overwriting and creation of files/folders slightly easier. The same file mapping as in the previous section is being done, except the files are now being copied to their proper location inside the newly created dist folder.
Additionally, I'm explicitly creating blank index.js files, since we're now making a proper ember addon and the various treeForX operations are no longer required.
I have a set of commands defined in /lib/commands with an index script which imports/exports all of them. The addon's index.js then provides an includedCommands through which these commands are loaded.
Unfortunately, with the way ember-cli addon discovery works, it seems it was never intended for us to create additional ember commands that can be called globally. Instead, they only work from the project folder where the addon providing them is installed. If this ever changes, it will make things simpler.
- ember-cli addon discovery finds our addon in the current project folder and figures out the
micro:componentcommand is defined there - command gets called from
lib/commands/component.js-verifyAndRunfunction is executed - command calls task from
lib/tasks/component.js- task does its thing
We're using an npm feature for this.
In package.json, we can define commands added by the npm package through the "bin" property:
"bin": {
"some-command": "path/to/script/that/executes/command.js",
"some-other-command": "path/to/some/other/script.js"
}
If the addon is installed locally, then these commands become available from the current folder. If it is installed globally, then they are available as global command line commands.
In our case, I implemented very basic wrappers which simply call ember-commands when one of the console commands is executed.
- A global command which was automatically added when installing the ember-micro-addon NPM package gets called
- The global command executes the script
lib/cli/componentbased on how it was defined inpackage.json - Script is a wrapper to
lib/commands/component.js - command gets called from
lib/commands/component.js-verifyAndRunfunction is executed - Command calls task from
lib/tasks/component.js
- Does or will ember-cli support the addition of global ember-commands, via installing the ember-addon globally, the way npm already does?
- What is the proper, conventional way to automatically/implicitly include styles into an ember app through an ember addon?