►
From YouTube: 2020-08-05 JavaScript SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
A
Okay,
so
the
first
thing
I
want
to
talk
about
is
the
the
plugins
node.
All
package
is
currently
broken
in
the
short
term.
We
just
need
to
release
contrib,
which
I'm
gonna
open
a
pr
for
that
today.
I
had
meant
to
get
to
that
yesterday,
but
it
slipped
through.
B
Yeah,
so
it
will
work
it
will
with
the
latest
with
all
the
latest.
It
will
work
fine,
but
if
we
again
release
the
minor
version
of
the
plugins
note,
all
it
will
be
broken
again
before
we
release
the
same
a
new
version
of
contrib,
so
the
all
the
plugins
will
use
the
new
version
of,
of
course,
api.
A
A
Okay,
so
I
think
the
plug-in's
core
can
stay
in
the
main
repo,
but
the
plug-ins
all
should
certainly
move.
I
believe
that
that
would
fix
this
issue,
yes,
and
that
that
would
be
all
we
need
to
do,
but
one
thing
that
I
think
we
should
consider
as
a
general
policy
is
making.
A
The
plugins
only
depend
on
the
api
and
not
depending
on
currently
they
they
all
depend
on
core
for
the
base
plug-in,
which
would
be
easy
to
move,
but
a
couple
of
them.
I
know
that
the
http
in
particular
depends
on
internal.
A
A
Does
anyone
have
any
reason
that
we
should
not
do
that?
It
would
be
probably
a
pretty
big
effort
for
one
thing.
B
B
A
I
think
it'll
be
a
pretty
large
chunk
of
work
and
before
starting
it,
I'd
like
to
merge
the
metrics
support
pr,
because
that
already
has
a
lot
of
plug-in
changes
and
I
don't
want
it
to
end
up
conflicting
a
ton.
So
I'd
like
to
merge
that
and
then
work
on
the
work
on
this
change.
A
B
A
B
Can
split
this
in
the
way
that
we
first
add
a
few
things
to
the
api
so
for
this
sometime
we'll
have
the
same
things
in
core
and
api
and
then
maybe
one
by
one
just
refactor
the
plugins.
So
it
will
be
easier,
small,
smaller
changes
and
once
we
finish
refactoring
all
the
plugins,
then
you
can
remove
this
from
car.
A
Yeah,
I
think
we
can
probably
do
it
one
by
one:
that's
probably
okay.
There
are
certainly
some
things
that
need
to
be
added
to
the
api
for
the
http
package,
but
I
think
for
the
rest
of
the
plugins.
They
only
depend
on
the
base
plugin,
so
I
think
they're
not
depending
on
too
much
internal
state.
So
the
change
should
not
be
all
that
drastic,
but
we'll
see.
A
But
moving
the
plugins
all
meta
package
into
the
contrib
repo
is
something
that
needs
to
happen
soon.
So
is
that
something
does
anyone
want
to
do
that
or
volunteer
for
that,
or
should
I
do
that.
C
I
can
take
that
on.
If
you
want,
if
there's
any
hidden
gotchas,
I
might
just
need
some
tips.
A
Very,
very
simple:
there's
only
like
three
files
in
the
meta
package,
you'll
see
when
you,
when
you
go
to
move
it,
it's
essentially
just
a
package
json,
it
doesn't
even
have
any
gis
files
in
there.
B
Before
you
delete
from
from
the
main,
I
would
say,
we
have
to
keep
it
until
the
contributor
will
have
it
matched
and
released.
Then
we
can
start
removing
this
meta
package
from
from
other
people.
C
So
move
it
to
contrib,
make
sure
it
lands
and
contrib
before
removing
from
the
main
repo.
B
Yeah
yeah
and
it's
it
needs
to
be
released
so.
A
Okay,
this,
after
thinking
about
it,
I
think,
is
a
bad
idea,
so
I'm
gonna
get
rid
of
that.
A
We
already
talked
about,
depending
only
on
the
api,
that's
a
long
term
change,
but
after
the
met
the
meter
support
is
merged.
I
will
probably
start
working
on
that.
A
Somebody
who,
I
believe
is
not
here
today,
has
a
pr
open
to
run.
The
w3c
trace
context
test
suite
against
our.
A
And
I
looked
at
a
lot
of
the
test
failures
that
we
have,
and
some
of
them
definitely
need
to
be
fixed,
but
some
of
them
around,
especially
the
trace
state.
The
test
suite,
is
actually
significantly
stricter
than
we
are.
So
it
wants
us
to
drop
the
trace
state
in
a
lot
of
cases
where
we
just
kind
of
ignore
illegal
entries,
and
things
like
that.
C
Yeah
because
I
think
that's
what
like
you
know
at
new
relic
and
about
other
places,
but
I
think
we're
just
matching
the
lowest
strictness
level,
because
it
does
get
pretty
pretty
strict.
A
So
for
that
I
think
I
I
I
would
tend
to
say
I
would
not
want
to
be
that
strict.
I
started
trying
to
play
with
the
trace
state
parser
to
pass
the
tests,
and
the
biggest
issue
is
not
that
it's
hard
to
make
them
pass.
A
It's
that
it
makes
the
propagator
significantly
slower,
because
you
have
to
do
a
lot
of
checks
that
we're
not
doing
right
now,
and
I
just
don't
think
that
that's
a
great
trade-off
so
I'll
make
a
comment
on
this
pr,
then
to
have
him.
Try
strict
level
two
and
we'll
see
where
that.
A
A
C
So
I
just
did
a
quick
look,
it
looks
like
one
is
less
strict.
So
if
it's
running
on
one
that
might
be
the
lowest
level,
it
can
go.
A
A
If
you
have
two
incoming
keys
that
are
the
same,
it
wants
you
to
drop
the
whole
trace
state
where
currently
we're
just
taking
the
first
one.
Do
you
know
it
new
relic
how
you
guys
handle
the
cases
like
that?
Are
you
fully
passing
the
the
test
suite.
C
C
A
Yeah,
I
let's
see
the
cases
are
here,
so
these
are
the
ones
that
I
had
not
yet
changed
to
pass,
so
we
have
like
the
illegal
vendor
format,
keys
and
again.
This
is
something
that
like
should
we
be
validating
keys
that
are
not
ours.
Yeah.
C
A
C
Yeah,
so
we
will,
we
won't
drop
the
whole
header,
and
I
don't
think
that
I
might
be
wrong,
but
I
don't
think
that
test
case
actually
wants
to
drop
the
whole
header.
We
will
drop
the
key
for
anything,
that's
or
we'll
drop
yeah,
we'll
drop
that
whole
trace
state
entry,
but
I
don't
think
we'll
drop
all
of
the
vendors
in
that
tray
state
in
that
situation
and
I'm
pretty
sure,
and
we
we
definitely
pass
at
level.
One.
A
So
I
guess
I'll
look
at
the
the
strictness
levels
that
are
available
and
I'll
try
to
get
these
passing
locally.
Before
I
make
too
many
comments
on
his
pr,
I
guess.
C
Yeah
or
or
if
you
want
that's
another
thing
I
can
take
on,
I'm
definitely
happy
to
let
you
do
that.
But
since
I
have
some
familiarity
I
know
you
have
a
lot
going
on.
A
Okay,
so
this
is
this
one's
a
big
one.
There's
a
lot
going
on
here
around
plugins.
I
think,
as
we
approach
ga,
we
want
our
plug-in
story
to
be
very
solid,
because
when
we
go
to
1.0
we're
going
we're
expecting,
I
think
the
community
to
start
supporting
more
plugins
and
expect
more
stability.
A
A
The
first
is
the
metrics
support
pr,
I
think
almost
everybody
is
aware
that
this
exists,
but
I
would
appreciate
it
if
people
would
review
it.
It's
had
a
long
running
review
process
and
there
have
been
a
lot
of
changes,
but
it's
still,
I
believe,
only
has
one
approval,
so
I
really
need
people
to
look
into
that
pr,
because
it's
blocking
changes
that
I
want
to
do
for
a
lot
of
these
other
things.
A
The
second
issue
and
actually
is
probably
more
important,
is
a
load
order
issue.
So
currently
because
of
the
way
that
resource
detection
works,
we
actually
cannot.
A
Instrument
node
fetch,
because
resource
detection
is
done
before
plugins
are
loaded
and
node
fetch
is
already
in
the
require
cache
when
the
plugins
start
up.
The
node
fetch
has
already
created
an
http
agent
under
the
hood.
So
when
we
pack,
when
we
patch
the
http
module,
node
fetch's
agent,
is
not
end
up
being
patched.
A
A
Now
the
the
bulk
of
that
work
is
actually
done
in
the
metrics
pr,
but
the
metrics
pr,
I
believe,
does
not
fix
the
load
order
issue
it
only
it's
a
just
a
prerequisite
to
actually
fix
it.
A
So
I
don't
know
who
here
is
familiar
with
this
issue,
but
this
is
something
that
I've
been
looking
into
and
is
pretty
deeply
rooted
in
our
in
our
system.
Right
now,
two
things
need
to
happen.
To
fix
this,
the
load
order
needs
to
be
changed.
A
While
that
wouldn't
actually
fix
this,
it
would
mitigate
it
because
if
you
don't
install
the
gcp
metadata
detector
that
this
wouldn't
have
been
a
problem,
so
I
suppose
right
now,
the
the
takeaways
are.
Please
review
the
metrics
support
pr
and
I
need
somebody
to
either
volunteer
or
I
will
do
it.
I
guess,
but
somebody
needs
to
split
the
resource
detectors
out
of
the
sdk,
so
they
need
to
be
hosted
as
separate
packages
so
that
they're
separately
installable.
C
No
one
else
takes
a
second.
I
can
just
take
that.
A
I'm
sorry
who
was
that
I'm
mark
mark
wolfe
okay,
so
I'm
just
going
to
tentatively
put
you
here.
A
A
Part
of
that
is
going
to
be
deciding
whether
these
resource
detectors
live
in
the
main
repo,
or
I
believe
that
they
should
probably
at
least
the
vendor
specific
ones
like
gcp
metadata
and
the
aws
detector
should
probably
be
moved
to
contrib.
Does
anybody
agree
or
disagree
with
that.
A
Yeah
I
mean
we've
been
trying
to
push
as
much
vendor
specific
stuff
out
as
possible,
like
with
the
propagators
and
things
like
that,
I
think
we
even
said
we're
not
going
to
host
them
with
the
resource
detectors.
A
C
A
A
As
we
approach
ga,
we
may
want
to
think
about
having
them
host
them
on
their
own,
but
I
think
that's
a
bridge
we
can
cross
when
we
get
there,
so
I
guess
mark
when
you
move
them
into
their
own
packages.
A
The
vendor
ones
will
go
into
contrib,
but
the
environment
variable
one
I
think,
can
stay
in
the
main
repo.
Does
that
sound
good
to
you.
A
Another
thing
that
we
already
talked
about
is
that
plugins
depend
on
core.
I
believe
that
plugins
should
only
depend
on
the
api
we
already
went
through.
That.
A
The
there's
a
flaky
test
in
the
sdk
package-
and
I
was
looking
into
this
test
and
the
reason
that
it
flakes
out
is
that
it
takes
too
long
if
frequently
nci
takes
more
than
two
seconds,
which
is
the
test
timeout
by
default
and
on
my
local
machine.
It
usually
takes
somewhere
around
a
second
or
somewhere
just
under
a
second,
and
the
issue
is
that
it's
trying
to
load
every
single
plugin
when
the
tracer
provider
is
starting
and
the
test
is
testing
the
sdk
starting
up
a
tracer
provider.
A
So
that's
what
the
it
should
actually
be
running,
but
there's
no
good
way
to
disable
plug-in
loading
when
you
start
a
tracer
provider.
So
again,
the
fix
for
this
depends
on
this
metrics
support
pr.
A
B
A
Yeah
as
a
temporary
workaround,
that
probably
is
fine
yeah.
I
guess
I
will
I'll
just
make
a
small
pr
to
do
that
after
the
meeting.
A
Today,
okay,
another
thing
that
once
this
metric
support
pr
is
done.
A
If
we
move
the
plugins
to
only
depend
on
the
api
and
have
the
plugin
loader
be
a
separate
part
outside
of
the
tracer
provider,
it
probably
no
longer
makes
sense
to
keep
open,
telemetry
web
and
open
telemetry
node
as
separate
packages,
because
the
only
difference
between
them
are
the
plug-in
loaders
and
the
default
context
manager.
A
Obviously,
this
depends
on
a
lot
of
work,
having
already
been
done,
but
what
would
you
guys
think
about
removing
the
node
and
web
specific
tracer
provider
packages
bart
in
particular?
Are
you
aware
of
any
other
differences
that
I'm
not
thinking
of
right
now?
That
might
that
this
might
be
a
problem.
B
A
Yeah,
so
now
that
the
plug-in
loading
is
a
separate
module,
I
think
the
difference
between
them
is
a
lot
smaller.
B
A
B
A
Think
there's
there's
too
much
work
that
needs
to
be
done
before
we
can
do
this
and
I
don't
know
what
the
state
will
be
when
we
get
there.
So
I
think
that
this
is
not
an
immediate
priority,
but
it's
something
that's
been
in
the
back
of
my
mind
for
a
while,
but
I
guess
we
don't
there's
no
immediate
action
on
this
now.
So
I
just
wanted
to
make
you
aware
of
the
that
that
I
was
even
thinking
about
it.
A
So
caroline
brought
this
issue
up
and
I
don't
remember
caroline,
are
you
on
the
call?
I
believe
you.
A
So
I
don't
remember
what
the
initial
issue
is
that
you
brought
this
up
for,
but
I
think
there
are
a
lot
of
other
cases
where
this
is
also
useful.
So
do
you
want
to
talk
about
your
original
issue
that
you
had.
E
Yeah
sure
so
the
issue
for
me
was
I'm
working
on
a
happy
plugin
and
they
recently
moved
their
module,
mostly
just
in
terms
of
the
naming
schema
from
just
directly
calling
it
happy
to
at
happy
slash,
happy
and
right.
Now.
Both
versions
are
supported
still
and
both
remain
pretty
popular.
There's.
A
lot
of
people
who
still
haven't
migrated
over
to
the
newer
version,
and
ideally
the
plug-in,
would
instrument
both
and
right
now
like
functionally.
E
It
works
completely
to
instrument
both,
except
for
that
naming
difference,
and
this
issue
really
comes
into
play
in
when
the
plugin
itself
is
loaded.
You
just
pass
in
like
a
module
name
and
it
has
to
match
the
version
here
that
you're
using
so
I
was
working
through
a
few
possible
ideas
for
solutions,
and
I
was
thinking
one
way
to
do.
This
would
be
to
have
the
base
plug-in
class
support,
either
a
single
module
name
string
or
an
array
of
strings,
and
I
was
wondering
yeah.
A
A
I
don't
know
I
I
haven't
looked
into
how
that
affects
plug-in
loading
and
how
easy
that
would
actually
be
to
implement
on
the
plug-in
loading
side.
But
my
initial
thought
is
that
that
sounds
reasonable.
A
E
I
have
so
I
have
about
a
week
and
a
half
left
in
my
internship,
and
I
think
I
could
do
some
more
initial
research
into
it.
I'm
not
sure
that
I'll
be
able
to
finish
it
if
it
does
end
up
being
a
bit
more
involved
that
I
can
handle
tackling
it
originally.
A
F
Yes,
but
I'm
going
through
my
mouth.
F
A
A
Okay,
I
so
I
know
a
lot
of
you
guys
have
open
issues
in
prs
and
I
want
to
make
sure
that
those
don't
get
left
just
you
know,
turned
into
zombies
when
you
guys
leave.
A
A
So
would
you
guys
do
me
a
favor
and
as
your
internships
are
coming
to
an
end,
just
mention
on
whatever
pr's
you're
on
tag,
the
maintainers
group
and
let
us
know
that
your
internship
is
coming
to
an
end
and
we
can
work
something
out
where
either
you
know.
One
of
the
maintainers
can
probably
take
over
ownership
of
the
pr
or
something
like
that,
just
to
make
sure
that
they
don't
end
up
left
as
zombies
forever.
A
I
mean,
hopefully
we
should
get
them
merged
before
the
internships
end.
That's
that's
the
goal,
but
if
it
doesn't
happen,
just
do
me
a
favor
and
please,
let
me
know
on
the
pr
when
the
end.
A
Okay,
so
I
guess,
since
most
of
the
interns
are
leaving,
I
will
I'll
handle
this
supporting
multiple
plugins
change,
the
happy
plugin
caroline,
I
was
looking
at
the
contributory
bone.
I
didn't
see
a
pull
request
for
the
happy
plugin
is
that
one
already
merged.
E
E
Making
it
look
like
you
know
a
lot
more
files
had
changed,
so
I
was
hoping
to
wait
for
the
koa
pr
to
merge.
Hopefully
today
and
then
I
can
make
the
other
pr
as
soon
as
that's
ready.
A
Got
it?
Okay,
I
don't
know
if
you
saw,
I
did
request
a
change
on
the
koa
instrumentation,
it's
very
minor,
because
we've
had
releases
recently.
Your
versions
are
out
of
date
in
your
package,
jason.
D
E
Okay,
yeah,
I
did
go
ahead
and
bump
the
version,
but
for
the
open,
telemetry
core
dependencies,
some
of
those
sort
of
started
breaking
my
test
cases
and
I
wasn't
sure
if
this
was
something
other
people
had
run
into,
but
it
seemed
like
it
was
an
issue
with
kind
of
the
random
span
id
function.
E
A
E
I
can
I
can
keep
looking
through
that.
I
was
just
wondering
if
anyone
else
had
seen
any
breaking
changes
with
the
new
bumps
on
the
core
dependencies,
but
that's
all
right.
A
I
have
not
seen
that
and
we
actually
just
updated
all
of
the
existing
plugins
and
they're
all
of
their
tests
passed.
So
I'm
I
will,
after
the
call
I'll
take
a
look
at
your.
You
said
you,
you
pushed
the
branch
to
your
fork
right.
E
A
Yeah,
can
you
just
push
it
even
if
the
tests
are
failing
just
so
that
I
can
see
the
failures
and
maybe
help
you
work
through
it.
A
A
Actually,
they
specifically
called
out
the
x-ray
one
in
the
specification.
So
there
is
now
there
is
now
a
wording
in
the
spec
that
I
believe
the
word
they
used
is
encouraged.
Yeah
additional
propagators
implementing
vendor-specific
protocols
such
as
aws
x-ray,
are
encouraged
to
be
maintained
and
distributed
by
their
respective
vendors.
A
So
I
know
we
talked
about
that
last
week
and
I
just
wanted
to
let
you
guys
know
that
the
spec
did
eventually
settle
on
that.
So
that's
that's
the
current
state
of
that.
I
know
that
kong.
You
have
an
open
pr
for
the
x-ray
propagator,
I'm
happy
to
review
it
and
help
you
get
the
code
into
a
into
a
solid
state,
but
it
would
be
better
if
aws
could
host
that
on
their
own.
A
F
A
Especially
for
you
know,
we
just
mentioned
a
lot
of
the
interns
their
their
internships
are
ending,
so
it
would
be
nice
if
we
could
get
those
prs
reviewed
and
merged
before
they
leave,
so
that
does
include
the
metrics
support
pr
that
I
have
mentioned
like
25
times
already
on
this
call,
so
in
case
you
weren't
aware,
I
would
like
you
guys
to
please
review
that
one.
A
G
So
it's
just
the
way
I
handled
the
new
node
sdk
package.
I
was
just
returning
the
plugin
manager
because
I
thought,
maybe
because
of
the
stop
method
in
there
and
maybe
other
stuff
that
would
be
added
to
the
plugin
manager
later
on.
A
I
think
the
the
sdk
module
is
essentially
it
intentionally
does
not
return
access
to
any
of
its
internals.
So
you'll
notice,
you
don't
get
the
tracer
provider
back.
You
don't
get
the
meter
provider
back.
It
just
registers
all
with
the
api.
A
A
A
better
solution
to
this
would
be
to
add
a
shutdown
method
to
the
sdk
which
actually
shuts
it
down,
but
I
believe
that
should
be
handled
in
a
follow-up
pr
all
right.
So
I
think
for
now
don't
return
this
from
start
leave
this
as
you
know,
void
or
promise
to
void,
or
whatever
it
was
before
all
right,
and
then
you
know
follow-up
pr.
H
I
just
wanted
to
call
out
about
my
react
plugin.
I
just
want
to
call
it
because
it's
my
last
week
of
my
internship
and
it
looks
like
quite
a
big
pr.
There's
64
files
changed,
but
around
like
40
of
them
are
related
to
example,
code.
A
Yep
no
problem-
and
you
know
other
interns,
I'm
sure
having
the
same
issue
or
their
internships
are
coming
to
an
end
and
they
don't
want
to
see
their
work
go
nowhere.
So
please
review
plugins
particularly
pay
attention
to
the
the
intern
plugins,
as
they
are
all
sort
of
in
the
same
position
where
the
internships
are
ending.
A
A
A
Okay,
so
I'll
create
the
label,
because
I'm
not
I
don't
want
to
miss
anyone.
Can
you
guys,
please
all
just
comment
on
your
issues
to
please
you
know,
ask
me
to
please
add
the
label,
and
when
I
get
the
notification
I
will
add
them.
Okay,.
A
No-
and
I
guess
I
will
talk
to
you
all
next-
is
there
any
of
the
internships
ending
before
next
week's
meeting
yeah
on
friday
as
well?
That's
reza
and
tina
both
end
on
friday,
yeah.
D
David
putin
yeah
and
me
david,
oh
wow,
okay,.
A
We
really
appreciated
it,
and
I
hope
that
you
found
this
to
be
a
positive
experience,
and
I
do
want
to
make
it
clear
that,
just
because
your
internship's
ending
you
don't
have
to
stop
working
on
it,
it's
an
open
source
project
for
a
reason,
so
any-
and
all
of
you
are
welcome
to
continue
working
on
the
project
if
you
want
to
obviously
no
obligation,
but
I
just
just
want
to
say
thank
you.
A
And
I
will
talk
to
most
of
you
next.