-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
feat: Add @sentry/ember #2739
feat: Add @sentry/ember #2739
Conversation
This will add the `@sentry/ember` package. This will provide an Ember addon that fits into the Ember ecosystem and will in the future offer custom framework specific functionality. Once #2736 and other tracing PR's have landed, we can add Ember specific performance instrumentation.
packages/ember/LICENSE
Outdated
@@ -0,0 +1,29 @@ | |||
BSD 3-Clause License |
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.
We should use MIT license, forgot to say this for react :/
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.
Yeah it was MIT but I switched it because of react, 👍
packages/ember/.editorconfig
Outdated
@@ -0,0 +1,19 @@ | |||
# EditorConfig helps developers define and maintain consistent | |||
# coding styles between different editors and IDEs | |||
# editorconfig.org |
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 we discuss this as a global change, IMO we should be discouraging per package editor config + the whitespace and newline stuff should be taken care of by prettier.
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.
Generated 😄. I'm fine with using other config to align with the mono-repo, but this is the config that pretty much every Ember addon uses (once again, strong conventions).
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.
Hmm. Alright lets keep it then, but defer to @HazAT for any thoughts.
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.
Yeah, I am also a bit torn here, I would prefer not to have this.
If we want to have this, we should intro this mono repo wide (which should be another PR) so please remove it for now.
|
||
Setting `disableAnalytics` to true will prevent any data from being sent. | ||
*/ | ||
"disableAnalytics": false |
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.
cool TIL. Maybe we should do something similar for sentry-cli
@kamilogorek (unless this already exists).
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.
We don't send any analytics in sentry-cli afaik?
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.
Ignore my previous comment then 😅
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.
Last I remember it uses leek
to send build metrics to GA. It lets the Ember team know how addons and apps are being built and issues with the pipeline so they can design against actual usage vs. theoretical.
'.eslintrc.js', | ||
'.template-lintrc.js', | ||
'ember-cli-build.js', | ||
'index.js', |
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.
Wait why the eslint config? is it just autogenerated?
I know tslint sucks, and we are looking to update to eslint soon.
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.
Most of this is auto-generated for Ember addons, it's IMO best to leave addon settings as they are all built the same, which encourages community support. Upgrading for changes to ts/es linting rules in the future is simpler too as there are usually simple migration paths for most things if you follow Ember conventions.
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.
Gotcha lets keep it then.
…tryForEmber is called
…ror, and adjust config so that config for Sentry is separate, similar to how other Ember 'wrapper' addons use config
size-limit report
|
…ev mode when testing the dummy application
…included instead of special casing transport
7b4240d
to
1734c00
Compare
1734c00
to
6adacee
Compare
packages/ember/package.json
Outdated
"repository": "git://github.com/getsentry/sentry-javascript.git", | ||
"homepage": "https://github.com/getsentry/sentry-javascript/tree/master/packages/ember", | ||
"author": "Sentry", | ||
"license": "BSD-3-Clause", |
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.
"license": "BSD-3-Clause", | |
"license": "MIT", |
packages/ember/.editorconfig
Outdated
@@ -0,0 +1,19 @@ | |||
# EditorConfig helps developers define and maintain consistent | |||
# coding styles between different editors and IDEs | |||
# editorconfig.org |
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.
Yeah, I am also a bit torn here, I would prefer not to have this.
If we want to have this, we should intro this mono repo wide (which should be another PR) so please remove it for now.
@@ -0,0 +1,32 @@ | |||
# compiled output |
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.
Kind of nitpicking but all our other npmignore
files look something like:
*
!/dist/**/*
!/esm/**/*
which is far easier to understand and also less error prone. So instead of adding everything and ignoring specific things, we do the opposite of, first ignore everything and then we pick what we actually want.
I guess this is some kind of ember boilerplate, but are we may be able to come up with something similar?
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.
No problem, I don't mind going through the effort of changing it, but the npmignore is generated by the blueprint for Ember addons, which gets updated if the file layout ever changes (which it might soon enough). Every other Ember addon uses the same .npmignore. If any updates to the file structure happen we can simply just run the blueprint command again and use the new npmignore without having to go in to determine which of the files may or may not be used by the addon ecosystem in some way.
tldr; leaving as is is more maintainable, as the file structure for Ember addons is convention based.
} | ||
``` | ||
|
||
### Additional Configuration |
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.
Should we mention something here about our existing ember
integration in @sentry/intergrations
?
Like this package is the successor or something.
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.
Should it be here in additional configuration or above under general?
packages/ember/package.json
Outdated
"@sentry/browser": "^5.20.0", | ||
"@sentry/types": "^5.20.0", | ||
"@sentry/utils": "^5.20.0", |
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.
"@sentry/browser": "^5.20.0", | |
"@sentry/types": "^5.20.0", | |
"@sentry/utils": "^5.20.0", | |
"@sentry/browser": "5.20.0", | |
"@sentry/types": "5.20.0", | |
"@sentry/utils": "5.20.0", |
These should be fully version locked, otherwise lerna has troubles.
packages/ember/tsconfig.json
Outdated
"target": "es2017", | ||
"allowJs": true, | ||
"moduleResolution": "node", | ||
"allowSyntheticDefaultImports": true, | ||
"noImplicitAny": true, | ||
"noImplicitThis": true, | ||
"alwaysStrict": true, | ||
"strictNullChecks": true, | ||
"strictPropertyInitialization": true, | ||
"noFallthroughCasesInSwitch": true, | ||
"noUnusedLocals": true, | ||
"noUnusedParameters": true, | ||
"noImplicitReturns": true, | ||
"noEmitOnError": false, | ||
"noEmit": true, | ||
"inlineSourceMap": true, | ||
"inlineSources": true, | ||
"baseUrl": ".", | ||
"module": "es6", | ||
"experimentalDecorators": true, |
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 we somehow reduce this and align it with other tsconfig.json
we have in other packages.
This file should really only contain what absolutely necessary and ideally, extend our root tsconfig.json
like other packages.
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.
I'll take a look 👍
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.
I've extended and reduced it like you mentioned, but again Ember is conventional with which typescript it uses (modules are aimed at es6 and decorators are strongly encouraged to use in Octane). Guidance around settings in Ember is to usually leave defaults unless you have a very specific reason to change them, and rely on tooling (automated cli tools, codemods, etc) to upgrade and update.
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.
Makes sense. What version of Ember will this support then?
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.
All supported LTS versions. They are tested with ember-try (see here: https://github.com/getsentry/sentry-javascript/pull/2739/files#diff-7545849fb3cdafe10c02f667d5efe2f0), I'll add a note to the README though.
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.
Looks good!
packages/ember/README.md
Outdated
import config from './config/environment'; | ||
import { SentryForEmber } from '@sentry/ember'; | ||
|
||
SentryForEmber(); |
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 we make this InitSentryForEmber()
to make it more explicit on what is going on?
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.
Nice, will do.
import { find, click, visit } from '@ember/test-helpers'; | ||
import { run } from '@ember/runloop'; | ||
import Ember from 'ember'; | ||
import sinon from 'sinon'; |
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 we make sure we use jest
for everything? I know this might be an ember default, but I would like to prevent multiple testing libraries.
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.
It's not really just a default, it's pretty much the only testing library that is tightly integrated with Ember. I prefer jest over qunit in general, but for Ember it's not nearly as nice to setup with other frameworks (the only other real option being Mocha) as the other helpers etc. are missing. We'd have to do a fair amount of groundwork to get it working with Jest.
On the other hand though, the guides and documentation are great for Ember, and aside from a few more tests for performance / profiling I don't imagine we'll have many to maintain.
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.
Ok I guess best tool for the job kind of thing. Let's keep with the defaults then 👍
.github/workflows/sentry-ember.yml
Outdated
run: yarn run lint --scope=${{env.lerna-package}} | ||
|
||
- name: Build dependent packages | ||
run: yarn build --ignore="@sentry/integrations" --ignore="@sentry/ember" --ignore="@sentry/react" --ignore="@sentry/apm" --ignore="@sentry/gatsby" --ignore="@sentry/node" |
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.
I think @HazAT just converted a bunch to GHA, can we just leverage those and add ember under test
?
We don't need to duplicate lint
and build
that way.
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.
I'll take a look, 👍
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.
Yeah took a look at the the GHA workflow and removed this, it's a lot simpler to just run the build for everything, it probably isn't worth dealing with managing individual workflows for a small speed increase.
} | ||
next(null, function () { | ||
warn( | ||
'Ember.onerror found. Using Ember.onerror can hide some errors (such as flushed runloop errors) from Sentry. Use Sentry.captureException to capture errors within Ember.onError or remove it to have errors caught by Sentry directly. This error can be silenced via addon configuration.', |
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.
Interesting. So we ask users to instrument Ember.onError
theirselves? Any reason we didn't opt for automatic instrumentation of Ember.onError
?
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.
Not quite, Ember.onerror
doesn't fully cover all error, just some of the errors within Ember. If someone doesn't have Ember.onerror
declared, then all errors will naturally forward to Sentry. If they do have onerror declared and are doing something with those errors, then a subset of errors might be getting ignored and not forwarded to Sentry, hence the warning.
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.
Oh, I misunderstood, that makes much more sense. Cool 👍
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.
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 will add the `@sentry/ember` package. This will provide an Ember addon that fits into the Ember ecosystem and will in the future offer custom framework specific functionality.
Summary
This will add the
@sentry/ember
package. This will provide an Ember addon that fits into the Ember ecosystem to replace the existing error reporting, and will in the future offer custom framework specific functionality. Once #2736 and other tracing PR's have landed, we can add Ember specific performance instrumentation.WIP - let me know if the broad strokes of this look correct
Other
Dummy Application
To test out and make sure using
GlobalEventProcessor
suffices in lieu of Ember's error hooks, as a lot has changed, RSVP is now replaceable with Promise etc., to do so added an instrumented app as the dummy test application. This can be used to give examples of instrumentation as well as directly via Ember's acceptance testing.Todo
GlobalEventProcessor
is sufficient in lieu of onerror.Ensure compatibility with v2 addon specLater when v2 addons are backwards compatibleCheck that it's tree-shakeable to reduce concerns about package size and it's impact on bundle.Later when v2 addons are backwards compatibleAdd Ember (and potentially Ember-data) versions as contextLeaving this out for now, not really that useful.