Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

es6 namespaced addons #1544

Merged
merged 1 commit into from
Aug 4, 2014
Merged

es6 namespaced addons #1544

merged 1 commit into from
Aug 4, 2014

Conversation

bcardarella
Copy link
Contributor

This will allow one to have modules in their addons that are namespaced under their addon's name rather than the application's namespace. Expects the following directory structures:

addon
└── mixins
    └── data-route.js
app
└── controllers
    └── people.js

Any modules in app/ will always be namespaced under whatever namespace the parent application has. This allows the addon developer to create common-sense defaults that get pulled into the application then can be overridden by the consuming developer in the parent project's app/ directory.

Any modules in addon/ will always be namespaced under the addon's name. This name is always forced to lower-cased & hyphenated. So:

"Ember CLI Some Addon" => "ember-cli-some-addon"

Then in whichever modules the consuming developer wants to use this module they can do:

import DataRouteMixin from "ember-cli-some-addon/mixins/data-route";

This feature will traverse the addon/ directory and build a list of modules from the available file names and merge this into app.importWhitelist after the addon's modules have been compiled to ES6.

This feature will compile the addon's assets into vendor.js and vendor.css. It does this by expecting the addon to compile its own assets into a single file then all addon's files are concat'ed into an addon.js then eventually concat'ed into vendor.js. However, this feature relies on a currently modified broccoli-kitchen-helpers module local on my machine. In order for this to work that module needs to accept an allowNone option passed into multiGlob. I have a diff here of what needs to be done to multiGlob: https://gist.github.com/bcardarella/9b53445896a862081a07. Then broccoli-concat needs to accept passing this option along. The reason is that addons might pass back nothing and concat needs to handle combining nothing into an addon.js file.

Other things still to be done:

  • jshint
  • styles
  • templates

@stefanpenner
Copy link
Contributor

nice

@bcardarella bcardarella mentioned this pull request Aug 4, 2014
@bcardarella
Copy link
Contributor Author

@stefanpenner @rwjblue this is good for review. It will currently fail until broccolijs/broccoli-concat#16 is merged and released.

If everything looks good I'd like to get this in ASAP then I will go back and DRY up the preprocessing between EmberApp and Addons

@rwjblue
Copy link
Member

rwjblue commented Aug 4, 2014

Looks like 0.0.8 of broccoli concat is out with that PR. Can you update the package.json?

I'm 👍 on this and am happy to merge once updated (and Travis is happy).

This will allow one to have modules in their addons that are namespaced
under their addon's name rather than the application's namespace.
Expects the following directory structures:

addon
└── mixins
    └── data-route.js
app
└── controllers
    └── people.js
Any modules in app/ will always be namespaced under whatever namespace
the parent application has. This allows the addon developer to create
common-sense defaults that get pulled into the application then can be
overridden by the consuming developer in the parent project's app/
directory.

Any modules in addon/ will always be namespaced under the addon's name.
This name is always forced to lower-cased & hyphenated. So:

"Ember CLI Some Addon" => "ember-cli-some-addon"
Then in whichever modules the consuming developer wants to use this
module they can do:

import DataRouteMixin from "ember-cli-some-addon/mixins/data-route";
This feature will traverse the addon/ directory and build a list of
modules from the available file names and merge this into
app.importWhitelist after the addon's modules have been compiled to ES6.

This feature will compile the addon's assets into vendor.js and
vendor.css. It does this by expecting the addon to compile its own
assets into a single file then all addon's files are concat'ed into an
addon.js then eventually concat'ed into vendor.js.

The EmberApp's registry is no passed into all preprocessors. This allows
the Addon to manage its own registry rather than rely on the private singleton.
@bcardarella
Copy link
Contributor Author

@rwjblue it's green, I'll merge in

bcardarella added a commit that referenced this pull request Aug 4, 2014
@bcardarella bcardarella merged commit 84d9250 into ember-cli:master Aug 4, 2014
@bcardarella bcardarella deleted the bc-namespaced-addons branch August 4, 2014 14:38
@bcardarella bcardarella changed the title [WIP] es6 namespaced addons es6 namespaced addons Aug 4, 2014
bcardarella added a commit that referenced this pull request Aug 4, 2014
supabok pushed a commit to supabok/ember-cli that referenced this pull request Aug 6, 2014
* upstream/master: (24 commits)
  Add 'Hide content' button in QUnit toolbar
  Add app.css to Bluprint.ignoredUpdateFiles
  more line-ending fixes
  Update CONTRIBUTING.md
  Don't error without vendor/
  update generator tests to have platform independent line-endings.
  some windows related path fixes (in the test suite)
  glob handling of mocha appears different cross platform abstract the problem away with node-glob
  Only use HistorySupport middleware when config has history or auto.
  Route blueprint should not change router.js with --dry-run
  Update package.json
  Fix History Support middleware to work with baseURL.
  Implement destroy command
  Update README.md
  Testing appveyor.yml
  Removed use of `memoize` in EmberApp. Allows multiple EmberApps to be instantiated.
  Updated CHANGELOG for ember-cli#1544
  Don't assume value of bowerrc directory
  Make history-support an addon.
  Move bower assets to bower_components
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants