-
Notifications
You must be signed in to change notification settings - Fork 255
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
drop @bugsnag/core/(client|event|session) exports #2317
Conversation
const external = [ | ||
'@bugsnag/cuid', | ||
] | ||
const external = [/node_modules/] |
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.
as i mentioned in previous PR i think its right that core externalises all its dependencies leaving the individual notifiers to bundle what they need
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 may be misunderstanding the point of the external dependencies, but why do we need node_modules here?
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 statement makes rollup treat all node_modules as external - see https://stackoverflow.com/questions/44844088/how-to-set-as-external-all-node-modules-in-rollup
This means that instead of pulling a load of code into the core bundle they contine to be referenced externally:
const require$$0 = require('error-stack-parser');
const StackGenerator = require('stack-generator');
const require$$2 = require('@bugsnag/safe-json-stringify');
const require$$0$1 = require('iserror');
const cuid = require('@bugsnag/cuid');
// esm version
import require$$0 from 'error-stack-parser';
import StackGenerator from 'stack-generator';
import require$$2 from '@bugsnag/safe-json-stringify';
import require$$0$1 from 'iserror';
import cuid from '@bugsnag/cuid';
The thing is if core
copied @bugsnag/cuid
into its bundle then a number of other plugins also did this then there would be multiple copies of @bugsnag/cuid
code and what's more different instances of it which may cause issues in some situations.
What I'm saying is that for all these shared libraries like core and plugins that are consumed by multiple notifiers they should externalise all their dependencies. Then its left to the notifier builds themselves to pull in a single copy of every external dependency (as you would always want for a browser build). You may or may not want this for a node notifier build, but this gives use the option.
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.
okay, understood! that definitely makes sense then. thanks! 👍🏻
@@ -0,0 +1,115 @@ | |||
export interface Schema { |
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.
schema
is now being exported from @bugsnag/core
- these are the manually crafted types for that (for now) - copied from the internal typings against the js source
This reverts commit 50bebe4.
@@ -1,12 +1,10 @@ | |||
import ClientWithInternals from '@bugsnag/core/client' | |||
import type { BugsnagStatic, Config, Client } from '@bugsnag/core' | |||
import { BugsnagStatic, Config, Client, schema as baseConfig } from '@bugsnag/core' |
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.
also exporting schema
now
Drop these importing directly from source and use the compiled assets in
@bugsnag/core
I first tried to split this by doing client only first but there were issue where the client was then referring to the compiled version of Event whilst other places referred to a different Event, that of the source code