►
From YouTube: 2022-06-08 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
C
A
B
A
C
C
There
is
before
that.
I
I
made
some
effort
to
split
up
the
otrp
transformer
package,
which
would
be
the
last
one.
That's
not
split
along
the
the
signal
lines,
metrics
and
traces,
and
there
I
think
we
came
to
the
conclusion
that
the
tree
shaking
will
will
fix
that
problem
anyway.
C
I'm
not
too
knowledgeable
on
this
topic
and
there's
also
a
second
issue
where
someone
else
is
asking
for
side
effects
force
to
be
set
in
the
package
json
to
to
enable
the
tree
shaking,
and
I
was
wondering
if
someone
who
has
a
bit
more
deeper
knowledge
on
these
topics
might
know
a
way
forward
or
wants
to
have
a
look
at
those
so
that
we
can
yeah
basically
basically
figure
out
how
to
how
to
deal
with
this
in
the
future.
D
Yeah
on
the
pre-shaking,
we
definitely
need
to
add
that
to
the
package
jsons
so
that
webpack
and
other
tree
shakers
can
know
that
they
don't
have
to
go
and
do
a
bunch
of
extra
work
to
keep
it
smaller
on
the
other
one
that
would
just
depend
on
dependencies.
I
I
would
very
much
it
was
part
of
the
web
sdk
investigations.
I'm
doing
this
is
one
of
the
aspects
I'll
be
looking
at
is
making
it.
A
D
So
historically
you
used
to
have
to
say
if
I
know
something
has
side
effects
you
you
needed
to
say
true.
Otherwise
it
got
removed,
webpack
changed
it
12
months
ago.
I
think
it
was
so
now
it's
a
hint
so
that
it
knows
it
doesn't
have
to
go,
and
you
know,
dig
deeper
into
the
code.
A
So
if
it
doesn't
have
side
effects-
and
it's
not
used,
it
just
doesn't
add
it
to
the
bundle
at
all
and
calls
it
a
day.
It
doesn't
doesn't
do
anything
smarter
than
that.
Yeah.
A
A
You
know
with
some
sort
of
a
ci
check
that
any
packages
that
we
add
this
side
effects
false
flag
on
that
they
actually
don't
introduce
side
effects?
I
assume
that's
not
possible
right.
D
Yeah,
not
not
the
wire
of
it
any.
If
there's
any
code
that
has
auto
initializing
code
or
sets
up
global
variables,
that's
the
one
we
have
to
say
there
is
a
side
effect
here,
but
I'm
I
haven't
gone
through
all
the
code
yet
to
for
the
minification
once
I've
done
that
I'll
probably
be
I'll
answer
that
definitively,
but
I
don't
know
and
there's
no
ci
to
do
it
either
right.
D
A
Got
it
and
the
side
effects
for
something
like
the
api
module,
which
does
definitely
interact
with
global?
I
mean
technically
that
has
side
effects,
but
you
have
to
call
a
function
in
order
for
them
to
be.
A
D
A
Okay,
so
that
function
doesn't
actually
have
like
that.
Even
the
api
doesn't
actually
have
any
load
time
side
effects.
I
believe
the
instrumentations
we
would
want
to
instrumentations
do
have
side
effects,
but.
A
Yeah,
so
if
that's
the
case,
if
we're
only
worried
about
load
time
side
effects,
I
think
we
actually
don't
have
any
modules
that
do
anything
at
load
time.
Just
because
that's
been,
I
think,
for
a
long
time
generally
accepted
to
be
sort
of
an
anti-pattern.
It's
a
bad
thing
to
do.
Yeah
yeah.
So
as
far
as
I
know,
we
have
successfully
avoided
that
everywhere.
So
it
might
be.
Okay
to
add
the
side
effects
false
on
every
package
for
load
time,
side
effects.
D
So
here
is
the
only
one
in
app
insights
that
has
it
and
effectively
it's
our
ship
module
control
v,
so
yeah,
if
you
go
down
on
line
32
is
the
side
effects
so,
instead
of
just
true
false,
it's
an
array
of
file
names
that
causes
side
effects.
So
if
those
files
files
get
dragged
in
then
those
they
have
to
be
there.
A
A
Reasonable
thing
to
implement
it
would
be
nice
if
we
could
have
some
sort
of
ci
check,
but
I
doubt
it's
possible
and
we
avoid
side
effects
anyways.
So
it's
just
one
thing:
we
have
to
make
sure
when
we're
reviewing
code,
that
people
are
not
introducing
global
side
effects,
yeah,
okay,
so
that
will
help
with
the
tree
shaking-
and
I
assume,
if
you're,
not
using
metrics-
and
you
do
use
the
otlp
transformer
that
will
help
with
that.
A
Okay,
so
I
think
we
have
a
a
resolution
to
move
forward
here.
We
will
add
the
side
effects
false
to,
hopefully,
all
the
packages,
but
at
least
most
of
them,
which
should
resolve
a
lot
of
these
types
of
tree
shaking
issues.
D
Nope
and
I
just
pasted
the
line
of
code
that
actually
causes
the
side
effect
for
app
insights.
So
the
way
this
one
works
is,
if
you
happen
to
call
that
function,
that
function
causes
those
side
effects
so
so
yeah.
If
the
code
doesn't
call
the
exposed
globals,
then
those
files
never
get
dragged
in
and
therefore
pre-checking
is
fine.
A
D
Yep,
so
if
webpack
drags
in
this
function,
it
knows
that
okay,
that
function
is
including
this
file.
So
therefore,
this
file
includes
a
side
effect.
Therefore,
it
can't
be
tree
shaking
out.
B
A
B
The
side
effect
like
the
definition
of
the
side
effect,
which
I
initially
understood,
that
is
only
load
time.
Side
effect
is
a
bit
convoluted
like
it.
I
feel
like
we
are
not
sure
which,
which
one
which
which
kind
of
side
effects
are
we
talking
about,
because
when
I
look
at
this
function
by
the
definition
we
had
before,
it's
not
having.
D
Yeah,
so
so
the
way
this
works
is
they
would
put
the
underscores
or
expose
global
tslib
as
a
global
function
somewhere
in
in
their
code,
which
then
causes
everything
to
get
dragged
in,
and
therefore
webpack
knows
how
to
resolve
from
that
by
default.
We
don't
call
this,
so
this
is
just
there
for
legacy
purposes,
because
we
auto
patch
the
we
replaced
yesterday
with
this
stuff.
A
A
We
have
this
global
util
where
you
register
a
global.
Would
you
then
recommend
we
add
this
file
to
the
to
the
side
effects
list
or
no,
because
this
only
happens.
If
the
user
calls
this
register
or
calls,
you
know
a
function
to
register
the
global
tracer
or
something
like
that.
A
D
D
It
might
need
to
be
there
a
side
effect,
because
if,
if
webpack
happens,
to
create
separate
bundles
where
you've
got,
the
initialization
bundle
is
separate
from
the
code,
that's
using
it
and
the
initialization
bundle
gets
taken
out
of
the
initial
page
load.
It
may
be
missing.
D
Yeah,
so
it's
probably
okay
in
that
case,
in
our
case
it
wasn't
okay,
because
you
compile
anything,
that's
typescript
and
that
automatically
puts
in
understanding
score
assign
an
extent.
In
this
case
we
would
expect
it
not
to
work,
and
it's
only
once
the
initialization
happens.
A
Because
you
were
replacing
globals
that
are
definitely
called
at
load
time.
You
know
in
large
typescript
projects
they're
definitely
called
all
the
time.
This
would
only
be
called
by
the
user
if
they
want
it,
and
if
they
don't
call
it,
then
we
don't
care
if
it's
shaken
out
or
not
yep
yeah.
I
think
it's.
D
A
I
would
not
want
to
do
this
without,
like
some
serious.
You
know
at
least
manual
testing,
right,
I'll,
probably
publish
it
under
a
different
name
or
something
or
a
beta
version,
or
tag
and
npm,
so
that
it
doesn't
go
to
end
users,
and
we
can
verify
that
it's
actually
working,
but
I
think
it's
okay,
based
on
my
understanding.
A
D
A
There's
a
global
error
handler
and
then
in
let's
see
encore
we
have
yeah
the
global
error
handler,
which
is
still
just
an
exported
function.
It's
not
actually
global.
That's.
A
I
got
it,
I
understand
okay
and
then
we
also
have
the
environment
utils,
which
read
globals,
but
don't
write
them
yeah
like.
A
A
Cool
okay,
so,
like
I
said,
I
think
we
will
do
this.
If
anybody
thinks
of
a
reason,
we
shouldn't
add
it
to
the
issue,
but
otherwise,
let's
see
if
this
is
assigned
to
anyone,
it's
probably
not
is
there
anyone
that
wants
to
take
this.
A
D
Probably
add
that
to
the
agenda
later
in
terms
of
because
the
sandbox
repo
hasn't
been
created
yet
so
I'm
just
doing
this
locally.
At
this
point,.
A
A
I
will
remove
the
stale
label
and
we
can
move
on
all
right,
ronno
you
are
here.
I
wanted
to
ask
you
about
this
pr,
mostly
because
I
don't
understand
the
reasoning
for
it
when.
E
A
Look
at
the
the
diff,
it
seems
like
everything
like
this
is
just
two
different
ways
to
achieve
same
thing.
B
Exactly
right,
except
when
you,
when
you
extend
the
the
class
it
changes
only
when
you
do
that
and
with
those
changes
it
actually
always
looks
at
the
extended
class.
B
Otherwise
you,
whenever
you
want
to
change
the
registered
propagators
or
exporters,
you
also
have
to
change,
since
it's
hard
coded
here,
the
basic
trace
provider
right
on
the
left,
you
always
have
to
override
two
parts
of
the
class.
Whenever
I
want
to
actually
change
the
the
static
data,
that's
in
the
class
stored
as
in
the
registered
exporters,
for
example,
I
also
have
to
change
the
method
that
uses
this
list
to
actually.
A
D
Is
registered,
propagators
go
static
or
is
that
on
the?
Yes?
Yes,
yes,
that's
that
yeah!
Okay,
because
I
think
a
better
way
to
do
this
would
be
to
introduce
a
non-static
method,
and
just
say
this,
so
that
if
you
do
overwrite
it,
you
can
do
it
that
way.
B
I
think
there's
pros
and
cons
for
both
approaches,
for
example,
that
would
that
would
have
that
would
require
the
user
to
basically
pass
the
registered
whatevers
propagators
or
or
exporters
to
the
constructor.
Am
I
right.
B
F
B
A
B
This
experimenting
with
this
was
that
if
we
make
the
class
more
generic,
perhaps
it
would
be
useful
for
the
other
distros
for
vendors
to
also
extend
this
class,
which
will
also
make
their
potentially
make
their
apis
in
the
form
of
this,
this
class
or
the
their
extended
class
from
this
kind
of
more
standard
so,
and
the
same
goes
with
the
sdk,
the
node
sdk,
which
is
right
now.
I'd
say
like
quite
like,
I
would
say,
like
locked
down.
B
It's
it's
somewhat
difficult
to
extend
without
basically
rewriting
all
the
code,
but
if
we
kind
of
slightly
refactor
some
of
those
classes,
those
could
be
become
more
useful
for
vendors
and
thus
make
it
more
likely
that
we
kind
of
share
the
same
api
around
actually
using
the
code.
We
have
already
have
in
the
hotel
project.
D
Yeah
until
when
you're
coming,
just
using
typo
is
fragile
and
from
a
minification
perspective,
damn
that's
a
lot
of
stuff
that
can't
be
modified.
B
D
B
I
wonder
how
how
different
is
it
from
the
previous
one,
because
that
also
the
previous
solution
also
yeah,.
D
It
only
lets
underscore
register
exporters
once
in
this
case,
you've
got
it
twice.
D
B
B
Yeah,
so
so
all
both
of
the
parts
with
ass
will
actually
be
ripped
out
in
in
any
minified
code.
If
I
understand
anything
about
javascript
and
but
but
the
rest
of
it
is
is
correct,
but
it
also
applies
for
the
left
part.
I
I
mean
we
can
argue
about
the
fact
that
this
constructor
this.constructor
is
somewhat
longer
than
basic
trace
provider,
but
other
than
that,
I
don't
think
there
is
a
much
of
a
difference.
A
Yeah
that
the
type
annotation
should
not
appear
in
minified
code,
I
think
you
may
be
conflating
it,
with
instance
of
which
is
used
at
runtime,
but
type
of
is
compiled
out.
A
I
think
in
fact
yeah,
but
in
this
case.
A
Yeah,
as
makes
it
a
type
annotation
which
it
is
stripped
out.
A
A
And
call
so,
then
that,
compared
with
what
we
had
previously,
which
didn't
have
any
it's
actually
shorter.
B
I
think
that
the
previous
version
wasn't
there
for
minification
purposes
and
that's
why
I
didn't
consider
yeah
any
of
that
either
like
I
don't
think
we
you,
I
don't
think
whoever
implemented
it
like
it
crossed
their
mind
that
hey,
let's,
let's
actually
fill
in
the
actual
class
name,
because
it
would
be
better
minified.
But
of
course
I
might
be
wrong.
A
A
Yeah,
it's
a
draft
anyway
yeah.
I
was
just
more
trying
to
understand
what's
going
on,
and
I
think
that
now
I
do
rauno
what
why
is
this
still
a
draft?
What
are
you
still?
B
I
I
actually
now
when
it's
green,
like
I,
I
basically
had
a
like
five
minutes
in
the
train
to
work
on
that
and
that's
why
it's
street
draft
I,
when
I
submitted
it,
I
wasn't
sure
whether
the
tests
would
pass,
or
maybe
I
missed
something.
So,
oh
I
get
it.
Okay,
I'm
just
basically
actively
working
on
it.
That's
fine.
A
Maybe
a
test
would
be
helpful
because
that's
definitely
you
know
relying
on
sort
of
the
internals
of
the
way
the
typescript
compiler
works
and
some
stuff
like
that.
It
would
be
fairly
easy
to
break
if
somebody
was
looking
at
your
code
with
all
the
this
is
and
the
you
know
the
typecasts
and
stuff,
they
may
revert
it
to
the
old
code,
accidentally
thinking
they're,
making
it
more
readable.
So
it
has
to
probably.
A
B
Typecast
and
I'll
I'll
address
it
in
the
in
the
pr.
With
some
questions,
the
typecasts
are
like
fairly
useful,
anyways,
so
I'll
just
post
a
couple
of
like
my
thoughts
around
this
in
the
pr
as
well,
and
we
can
take
the
discussion
there,
yeah
of
course,.
A
Okay,
from
my
perspective,
I'm
happy
to
move
on
here
me
too.
Okay,
we
still
have
this
same
bug
from
last
week.
It's
actually
from
the
week
before
with
the
async
hooks
contacts
manager.
I
have
not
heard
too
many
people
complaining
about
this,
so
it's
I,
I
don't
think
it's
affecting
too
many
people,
but
it
is
still
there.
I
have
not
had
time
to
look
into
it,
yet
I
wanted
to
just
bring
it
up
in
case.
A
Somebody
is
motivated
to
look
into
this
and
has
time
it
is
still
there
and
it
is
a
bug
with
a
fairly
fundamental
component
of
the
system,
so
I
would
like
to
get
it
fixed
eventually,
but
we
have
no
update
here
for
those
that
were
not
aware,
I
think
most
people
here
are
we
released
version
1.3.1
and
0.29.2
from
the
main
repo,
including
some
bug,
fixes
from
the
initial
rc
release.
A
And
just
before
this
meeting,
we
released
a
version
of
contrib
which
takes
advantage
of
those
modules,
so
I
we
merged
this
like
one
minute
before
the
meeting
started,
so
I
have
not
had
a
chance
yet
to
verify
that
nothing
went
wrong
there,
but
assuming
nothing
went
wrong.
The
latest
version
of
everything
should
all
be
compatible
now,
which
has
been
sort
of
an
ongoing
issue
when
we
have
releases
so
just
for
people
who
are
not
aware,
that's
released
as
far
as
the
metrics
ga
we
do
have.
A
A
Some
of
the
issues
are
tagged
as
up
for
grabs,
but
really
any
issue
that's
not
assigned
is,
should
be
assumed
up
for
grabs
if
nobody
is
definitely
working
on
it.
So
these
these
down
here.
I
think
these
are
likely
also
up
for
grabs,
so
I
will
just
label
them
now.
A
And
legendicus
can
yell
at
me.
If
that's
wrong,
we
also
are
woefully
under-documented
on
the
latest
metrics
sdk
each
one
of
the
sort
of
unchecked
checkboxes
here
is
its
own
issue.
That
needs
to
be
resolved
from
a
documentation
standpoint.
A
A
B
I
I
don't
disagree,
but
but
I
I
don't
know
how
other
seeks
to
it,
but
is
there
any
practice
anywhere
set
up
to
actually
bring
in
the
changes
from
the
repo
I
mean
there
is
a
benefit
of
having
the
documentation
closer
to
the
code,
so
they
wouldn't,
you
know,
lost
like
a
loose
sync
and
everything,
but.
A
A
The
biggest
problem
with
that
when
we
were
doing
that,
is
that
the
website
repo
has
its
own
build
process
and
linting
rules
and
various
things
like
that,
where
we
could
make
changes
to
the
documentation
in
our
repo
decide,
we're
happy
with
them
and
merge
them
and
then
go
to
the
website
repo
and
try
to
update
the
sub
module
and
the
website
build
would
break
so
then
we
would
have
to
come
back
to
this
repo
make
whatever
changes
broke,
the
build
and
fix
them
and
then
go
back
to
the
pr
for
the
website
docs
and
try
again
and
repeat
that
until
we
had
a
passing
build
and
then
that
would
be
merged
and
it
was
just
a
painful
process-
it's
not
that
it
can't
be
done,
but
it
meant
that
you
know
it.
A
It
took
like
a
week
just
to
update
the
website
for
docs
that
had
already
been
written,
and
I
was
the
person
doing
that,
and
I
did
it
like
twice
and
I
decided
that
I
hated
it
and
I
moved
everything
to
the
website
repo
at
that
time.
So
that's
all
the
tracing
and
context
documentation
is
already
over
there.
A
And,
as
far
as
I
know,
the
specification
isn't
doing
anything
particularly
interesting
to
make
sure
that
everything
works
and
all
these
links
appear
to
work.
A
So
maybe
this
has
been
improved
and
fixed
and
I
can
look
into
it
suppose.
For
now
the
decision
doesn't
necessarily
need
to
be
made.
We
can
try
sub
modules
again
and
if
it's
painful,
we
can
decide
not
to
do
it,
and
if
it's
not
painful,
then
that's
obviously
the
ideal
solution
would
be.
I
agree
to
maintain
the
documentation
as
close
to
the
code
as
possible.
A
B
Okay
and
let's,
I
guess,
let's
just
continue
as
we
were
and
not
try
any
optimizations
on
the
working
process
and
look
into
it
later
or
whenever
you
feel
like.
A
Yeah,
for
now,
we
can
definitely
maintain
the
docs
in
this
repository,
no
matter
what,
because
they
need
to
be
initially
written
somewhere,
and
this
is
where
the
this
is,
where
we
have
the
experts,
so
we
should
do
it
here.
A
Okay,
I
have
one
more
quick
question
about
the
changelog
format.
Actually,.
A
A
So
if
you
look
at
the
raw
version
of
this,
this
link
has
to
be
added
manually
and
the
user
names
are
not
nothing's
automatically.
Linkified
things
need
to
be
manually
linked
and
having
a
link
to
the
pr
is
really
helpful,
but
in
the
experimental
change
log
we
have
not
been
doing
that.
So,
if
you
look
at
these
none
of
these
link
to
the
pr,
so
I
would
argue
that
we
should
probably
start
linking
these.
A
So
I
was
going
to
make
a
pr
to
go
through
and
update
all
of
these
old
ones
to
include
links.
But
before
I
went
through
that,
I
wanted
to
make
sure
that
everybody
was
on
the
same
page
and
that
we
that
this
was
something
that
everybody
wants.
Or
will
everybody
think
it's
too
annoying
updating
the
change
log
with
manual
markdown
links.
F
For
those
using
it
and
relying
on
seeing
when
things
changed
and
some
details
of
how
they
changed,
having
the
links
here
is
huge,
especially
when
you
need
to
upgrade
your
version
of
hotel
js,
and
you
want
to
see
the
changes
that
have
been
made.
It's
it's
really.
A
lot
of
work
to
have
to
go
manually,
look
up
the
prs,
so
I
would,
I
would
definitely
be
in
favor
of
adding
the
link
there.
A
That
was
my
feeling
too.
I
I
wish
that
github
would
just
automatically
linkify
these
numbers,
but
I
understand
why
they
don't,
I
think
in
readme's
they
do,
but
no
other
markdown
files
get
that
automatic
link,
treatment.
A
So
I
guess,
unless
somebody
feels
strongly
against
it,
I'm
going
to
go
ahead
and
do
this
and
I
think
in
the
future.
We
should
try
to
maintain
that.
So
when
you
make
a
pr,
please
add
a
link
to
the
pr
at
least
whether
you
link
your
own
username
or
not,
doesn't
really
matter
to
me.
But
if
you
please
link
the
pr.
A
Okay,
beyond
that,
we
had
a
few
new
pr's,
but
they
actually
all
got
merged.
I've
listed
them
here
for
just
to
make
sure
everybody
is,
is
on
the
same
page,
the
only
one
I
think
here
that
might
be
a
little
bit
controversial.
Is
this
pr
which
removes
the
aws
and
gcp
resource
detectors
from
the
sdk.
A
Those
were
those
are
maintained
in
the
contrib
repo,
and
it
was
the
only
dependency
that
the
main
repo
had
on
the
contrib
repo.
It's
also
the
open
source.
You
know
default
sdk,
depending
on
vendor
specific
code,
which
is
a
little
weird.
I
was
in
support
of
this
change.
You
can
see
by
the
the
reviews,
at
least
valentine
and
legendicus
were
also
in
support
of
it.
A
Amir.
The
other
maintainer
here
is
on
the
call.
I
don't
know
whether
you
have
a
strong
opinion
or
not,
but
unless
somebody
is
very
adamant
about
not
doing
this.
I
support
this
change,
but
I
just
wanted
to
bring
it
up
because
it's
potentially
controversial.
A
In
the
auto
instrumentation
library,
are
you
the
node,
sdk
library
or
the
meta
package
library,
the
meta?
E
A
Fine,
that's
fine,
but
not
having
the
main
repo
depend
on.
It
is
okay
with
you.
A
Okay,
so
I
yeah
like
I
said
I
just
wanted
to
include
it
in
the
agenda
so
that
if
anybody
felt
very
strongly
about
it,
they
have
a
chance
to
speak
up,
but
if
not
we're
gonna
move
on
as
usual,
I
have
a
list
of
old
pr's
they're
only
getting
older,
so
some
of
these
have
been
around
for
a
while
and
are
still
in
need
of
reviews.
So
please
take
a
look
through
them,
particularly
this
last
one
is
a
metrics
pr
and
is
required
for
metrics
ga.
A
So
that's
an
important
one,
but
really
all
of
these
should
be
reviewed
and
either
accepted
or
rejected.
So
we
don't
want
them
to
just
sit
forever.
F
For
the
es
module
pr
from
what
it
looked
like,
the
the
last
thing
needed
is
just
a
couple.
Small
changes
for
valentine
to
do
was
that
still
looking
for,
like
other
feedback
aside
from
that
or
like,
is
there
something
else
that
we
should
be
looking
at
for
that
one.
A
No,
I
think,
right
now.
This
one
is
mostly
waiting
on
him.
He
has
limited
time
because
he,
while
he
is
a
maintainer,
he
is
actually
doing
it
in
his
free
time.
He
doesn't
have
a
lot
of
work
time
to
dedicate
to
these
things.
So
is
unfortunate,
but
it
is
the
way
it
is.
If
this
is
something
that's
important
to
you,
you
can
maybe
reach
out
to
him
about
taking
over
this
pr.
If
you
feel
like
you
could
get
it
over
the
finish
line
more
quickly.
F
Okay,
yeah
I'll
I'll
reach
out
to
him
and
see
if
there's
anything
that
new
to
help
out.
A
D
Yep,
so
that
that's
the
request,
it's
been
there
for
like
seven
days,
because
I
raised
it
last
week.
I
don't
know
who
is
going
to
be
creating
this
like.
D
I
know
daniel
if
you
want
to
reach
out
and
look
at
this
in
terms
of
local
progress,
just
so
that
I'm
not
waiting
for
this
to
get
to
happen
before
I
start
anything,
I'm
taking
local
copies
of
the
api
and
the
entire
js
repose
appending
sandbox
dash
to
every
single.
So
it's
like
open,
telemetry
dash,
sandbox,
js
and
api
et
cetera.
D
So
I
can
build
locally
as
part
of
that
I've
removed
learner
and
using
rush,
so
it
like
links
everything
locally
and
I'm
not
using
webpack
for
the
browser-based
stuff,
I'm
just
using
karma
typescript,
I'm
just
trying
to
get
it
all
going.
D
Well,
the
webworker
one
I
I
did
see
that
in
there
that
would
be
a
good
thing
to
have
as
well
and
yeah.
Once
I
get
it
going,
then
it'll
be
effectively
basically
ready
to
go.
My
my
view
of
what
the
sandbox
repro
is
going
to
be
is,
it
will
just
be
main,
will
be
a
case
of
where
we
do
this
manual
merge
because
of
the
pain
we've
got
to
go
through,
and
then
we
can,
you
know,
go
and
create
forks
and
local
pr's
to
hack
around
and
see
what
we
can
do.
C
D
I
don't
envisage
initially
we'll
need
to
publish
anything
which
I've
sort
of
put
in
in
this
request.
Eventually,
I
think
we
will
get
to
a
point.
We
might
want
to
publish
npm
packages
so
that
people
can
go
and
play
with
them,
but
again
those
packages
will
be
called
sandbox.
A
I
don't
know
who
fulfills
these
types
of
requests.
I
think
it's
the
tc.
I
know
I
don't
have
permission
to
and
I'm
on
the
governance
committee,
so
the
tc
is
the
only
group
left
really.
I
will
reach
out
to
armin
because
he
he's
on
the
tc
and
he's
a
coworker
of
mine
to
see
what
needs
to
be
done
here.
The
tc
meeting
is
today,
but
I
don't
know
what
time
so.
A
It's
possible
they're
already
talking
about
this,
but
I
I'll
make
sure
somebody
from
the
tc
is
at
least
looking
into
this,
because
it
looks
like
you've
gotten
really
no
feedback
at
all,
so
I'll.
Make
sure
that
it's
being
forgotten
about
yep
cool
thanks,
yep.
A
Okay,
well,
thank
you,
everybody
for
your
time
and
please
review
prs.
I
look
at
the
metric
ga
milestone
if
you're
looking
for
something
to
do-
and
I
will
talk
to
you
next
week.