-
-
Notifications
You must be signed in to change notification settings - Fork 120
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
Add debug tooling babel plugins. #133
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks awesome (but i did leave some nit-picks)
README.md
Outdated
@@ -95,6 +95,92 @@ treeForAddon(tree) { | |||
} | |||
``` | |||
|
|||
### Debug Tooling | |||
|
|||
In order to allow addons to easily provide good development mode ergonomics (assertions, deprecations, etc) but |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addons and apps?
README.md
Outdated
|
||
// ...snip... | ||
init() { | ||
this._super.init.apply(this, arguments); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth documenting how an addon would do this? This seems quite off the beaten path
Pushed an update for the two README tweaks that @stefanpenner mentioned... |
|
||
#### Debug Macros | ||
|
||
To add convienient deprecations and assertions, consumers (in either an app or an addon) can do the following: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a bulleted list of available macros, or a link to where they are documented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, updated!
Ensure logging filter for parallel stuff follows the existing convent…
Implements ember-cli/rfcs#50 and the
@ember/debug
portion of emberjs/rfcs#176.Below is the documentation being added to the README explaining the feature.
Debug Tooling
In order to allow addons to easily provide good development mode ergonomics (assertions, deprecations, etc) but still perform well in production mode ember-cli-babel automatically manages stripping / removing certain debug statements. This concept was originally proposed in ember-cli/rfcs#50, but has been slightly modified during implementation (after researching what works well and what does not).
Debug Macros
To add convienient deprecations and assertions, consumers (apps and/or addons) can do the following:
In testing and development environments those statements will be executed (and assert or deprecate as appropriate), but
in production builds they will be inert (and stripped during minification).
General Purpose Env Flags
In some cases you may have the need to do things in debug builds that isn't related to asserts/deprecations/etc. For
example, you may expose certain API's for debugging only. You can do that via the
DEBUG
environment flag:In testing and development environments
DEBUG
will be replaced by the boolean literaltrue
, and in production builds it will be replaced byfalse
. When ran through a minifier (with dead code elimination) the entire section will be stripped.Disabling Debug Tooling Support
If for some reason you need to disable this debug tooling, you can opt-out via configuration.
In an app that would look like:
In an addon that would look like: