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

Addon runtime and buildtime config #636

Closed
mehulkar opened this issue Jun 4, 2020 · 2 comments
Closed

Addon runtime and buildtime config #636

mehulkar opened this issue Jun 4, 2020 · 2 comments

Comments

@mehulkar
Copy link
Contributor

mehulkar commented Jun 4, 2020

Apps should automatically get a namespaced way to pass runtime and buildtime config that an addon can then access easily. Currently

  1. each addon makes up its own rules about where to read config from the parent app
  2. addons can supply default config to the app in config/environment.js (haven't tried this, not sure how it becomes accessible to the app).
  3. runtime and buildtime config can be under different keys.

Proposal is to make the name of the package the key in both ember-cli-build.js and in config/environment.js.

@jelhan
Copy link
Contributor

jelhan commented Jun 6, 2020

I think the v2 addon format should be taken into consideration. I hope the build-time macros will replace some of the run-time configuration. But I agree that there is still a need to standardize the rest.

I noticed how hart it is to get it right with the current primitives while refactoring the configuration interface of ember-cli-content-security-policy. Needed a few iterations until I landed on a solution that solved all problems. One problem I haven't thought of before: the configuration stored in ember-cli-build.js is only available in some build hooks. Finally landed with an addon specific configuration file config/content-security-policy.js.That seems to be the third established pattern beside config/environment.js and ember-cli-build.js.

Having three different locations for addon configuration doesn't feel like convention over configuration. And not having a naming convention for the keys used (config/environment.js and ember-cli-biild.js) or the filename (config/foo.js) doesn't help.

Not sure if the package name is a good convention. I know that's what most addons are currently doing. But:

  1. The package name contains dashes in nearly all cases. Property names with dashes don't provide a good developer experience in JavaScript. I think that's the reason why some addons use a camelized version of it's package name.
  2. Most package names are prefixed with ember. It doesn't help with readability if nearly all configuration keys start with the same term.

@mehulkar
Copy link
Contributor Author

I'm reading the v2 addon format RFC and this would be covered under there. Although I originally was thinking that the best way is to have a static key, the macro system proposed in v2 format describes a different configure system that would achieve the same goal of making it easier to pass around config. https://github.com/emberjs/rfcs/blob/master/text/0507-embroider-v2-package-format.md#build-hooks

Going to close this in favor of (already merged) #507.

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

No branches or pull requests

2 participants