►
Description
We were running into a weird Vue warning which was hiding the expected Jest failure. It turns out that some magical prop `_withStripped` which .vue compiles to is related!
Related branch: https://gitlab.com/gitlab-org/gitlab/-/tree/ps-recreate-pretty-print-issue
A
A
A
Yes,
we
would
get
that
the
property
or
method
no
type
is
not
defined
on
the
instance
but
referenced
during
render
very
strange,
but
what
we
then
observed
was
related
to
that
was
and
when
especially
when
mark
was
added
to
debugger
was
when
we're
trying
to
do
this
pretty
print
of
the
diffs,
because
there's
something
wrong
the
pass
failed.
So
we're
going
to
print
a
nice
pretty
message
to
the
end
user.
A
We
are
trying
to
pull
one
of
the
plugins,
for
pretty
format
is
dom
element
to
see
hey.
Is
this
even
a
dom
element
that
we
can
start
reading
from?
So
I
started
looking
for
no
type
and
tag
name
and
that's
what's
throwing
this
error
because,
as
we
all
know
and
view
if
in
a
template,
if
you
reference
something,
that's
not
actually
defined
on
it
it'll
blow
up
the
way
this
works
is
it
creates
a
proxy
when
everything
first
get
initialized
to
hey.
A
When
we
try
to
get
something,
if
it
doesn't
actually
exist,
then
we're
going
to
throw
a
warning
and
our
tests
blow
up
when
there's
warnings
so
we're
trying
to.
I
was
trying
to
create
an
isolated
example
to
recreate
this,
and
I
ended
up
creating
some
components
similar
to
what
mark
had
where
we're.
Having
some
data
that
we're
passing
down
to
a
child
component,
I
originally
had
as
a
template,
and
then
we
were
trying
out
the
render
function
but
and
I've
called
these
inline
child
inline
test.
A
So
what
is
going
on
and
one
of
the
main
differences
that
I
then
realized
between
mark's
environment
and
this
using
just
inline
functions
like
or
inline,
just
creating
components
off
the
fly
like
this
was
that
mark's
components
were
coming
from
different
files,
so
I
then
moved
these
to
different
files
and
when
you,
when
we
use
the
ones
that
are
loaded,
so
let
me
change
these
instead
of
the
n
line
ones.
I
guess
we
call
that
loaded
test
component
and
loaded
child
component.
A
Then
it
was
blowing
up,
so
what
could
possibly
be
going
on
and
yeah?
So
then
it
blows
up
with
the
no
type
issue,
and
one
thing
to
be
aware
of:
is
that
view
and
jest
uses
view
loader
and
so
the
end
results
that
are
actually
getting
imported
when
you
import
a
dot
view
file,
look
something
like
this
and
we
were
then
so
we
could
just
play
around
with
this
stuff.
A
I
then
copy
these
values
over
to
their
own
functions,
but
the
one
thing
we
realize
that
makes
all
the
difference
is
with
stripped.
So
if
I
use
these
these
inline
versions
of
what
actually
gets
loaded,
this
would
fail,
but
when
I
change
it
to
width
strip
equals
false
it'll
show
the
pretty
diff
yeah.
So
if
I
do
with
strip
instead
of
true,
we
do
with
false
and
we
have
another
one
it's
over
here.
A
Okay,
now
these
this
will
work,
and
so
what
we've
observed,
yep
yeah,
so
we've
observed
what's
actually
going
on,
is
when
we
have
with
stripped
as
true
the
proxy
that
gets
created.
It
only
creates
this
get
handler
when
it's
false.
It
only
creates
the
has
handler
and
what
mark-
and
I
are
kind
of
wondering,
is
why
not?
Why
don't
we
always
have
the
has
handler
and
maybe
that'll
help
with
our
when
we're
trying
to
iterate
through
these
properties
or
something
like
that?
Do
you
have
anything
to
add
mark.
B
I
was
just
digging
into
the
history
of
this
and
I
found
I've
linked
you
in
the
chat
there's
a
link
to
an
older
version
of
you,
so
the
latest
version
of
uloader
doesn't
have
this.
I
don't
know
why
it
must
be
buried
in
some
dependency
somewhere,
but
this
older
version
does
write
this
out
and
this
is
where
it's
coming
from,
but
there's
not
much
detail
about
it
just
says
mark
with
stripped.
This
enables
you
to
use
the
correct,
runtime
proxy
detection.
B
B
B
A
A
A
A
I
will
see
that
there
is
the
beautiful
observer
property,
that's
it's
trying
to
iterate
through
and
figure
out
what
to
do
with
this.
Ideally,
we
can
just
always
ignore
this
in
pretty
format
which
we
really
really
should.
I
don't
know
how
to
do
that
either.
So,
there's
there's
there's
multiple
things
going
on
here
for
sure.
B
B
A
Right
now,
depending
on
like
what
my
objective
was,
if
I
was
really
really
like,
maybe
I
was
doing
a
v
bind,
and
I
really
want
to
make
sure
well
that
these
props
are
just
these
props.
I
imagine
you
could
also
do
something
like
two
equal,
but
then
do
inside
of
things
like
an
expect.
Dot
object
match
or
whatever.
So
you
could,
because
it
is
just
this
nested
bit,
that's
causing
the
issue.
B
A
B
B
A
A
A
Interesting,
interesting,
okay,
yeah!
That's
an
interesting
point.
I
think
that
we
could
probably
solve
this
at
the
just
reporting
level
like
for
some
reason.
We
could
it.
We
need
to
be
able
to
tell
it
not
to
look
at
certain
things,
whether
we're
using
two
equals
or
two
match
objects,
which
would
be
nice.
B
A
A
A
A
A
B
So
it's
it's
doing
the
right
thing.
It's
just
it's!
So
it's
a
it's
a
confluence
of
you
when
not
in
production,
checking
for
property
accesses
and
changing
that
behavior,
depending
on
whether
you
are
using
a
view
loaded
component
or
a
component
with
a
template
literal,
I
guess
yeah
and
our
setup
of
of
throwing
failing
a
test
when
consoled
error
is
called
yeah.
Oh
man.
A
A
A
Oh
no,
these
are
still
the
same
thing
is
that
is
that
oh,
but
we
haven't
done
the
has
been
so.
Maybe
that's
causing
issues
anyways
or
maybe
has
on
property,
isn't
necessarily
the
right
thing
to
be
looking
for
here.
I
wonder
if
I
do.
Let
me
try
one
more
thing.
If
I
do
no
type
is
involved,
oh
and
no
type,
oh,
this
is
a
not
I
want
to
be
val,
and
it's
not
that
it
would
be
one
reason
why
it
would
fail.
A
It
it
does,
we
don't
get
any
errors,
and
that
would
be
an
interesting
upstream
fix
too.
Here
is
to
because
clearly
we're
saying
that
no
type,
I
don't
know
if
tag
name,
is
important.
Oh
yeah,
clearly
we're
saying
clearly
we're
requiring
no
type.
So
at
the
very
least
we
can
just
add
an
if
here
and
be
like
okay,
we
don't
have
no
type,
don't
move
forward
and
then
we
would
be
fine,
but
all
of
it
is
very
flaky
and
weird
anyways.
Thanks
for
watching,
I
guess
I'll
stop.