You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, we build the profiling node bindings in this repo, on each release (and in many PRs etc). Building these takes quite some time (up to 30 minutes), and can be pretty flaky, especially building the windows bindings. This slows down development and releases significantly.
What if, instead, we'd extract the native code & bindings part out of the monorepo, into a separate package? Then this package could be released separately, invoking cost of building & running these things only when the native code actually changes.
The @sentry/profiling-node package could remain in the monorepo and simply depend on the bindings package, e.g. @sentry-internal/profiling-node-bindings or something along these lines.
Disclaimer
I am by far not an expert on how the profiling-node package works, and maybe this is not possible at all. But something along these lines would be a good direction to go IMHO.
The text was updated successfully, but these errors were encountered:
Proposal
Today, we build the profiling node bindings in this repo, on each release (and in many PRs etc). Building these takes quite some time (up to 30 minutes), and can be pretty flaky, especially building the windows bindings. This slows down development and releases significantly.
What if, instead, we'd extract the native code & bindings part out of the monorepo, into a separate package? Then this package could be released separately, invoking cost of building & running these things only when the native code actually changes.
The
@sentry/profiling-node
package could remain in the monorepo and simply depend on the bindings package, e.g.@sentry-internal/profiling-node-bindings
or something along these lines.Disclaimer
I am by far not an expert on how the profiling-node package works, and maybe this is not possible at all. But something along these lines would be a good direction to go IMHO.
The text was updated successfully, but these errors were encountered: