text:
UAF: Access violation near NULL on destination operand

VIM Version:
$ ./vim --version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Oct 10 2019 22:18:57)
Included patches: 1-2133
Compiled by input0@zero
Huge version without GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_any_white
+arabic            +file_in_path      +mouse_urxvt       -tcl
+autocmd           +find_in_path      +mouse_xterm       +termguicolors
+autochdir         +float             +multi_byte        +terminal
-autoservername    +folding           +multi_lang        +terminfo
-balloon_eval      -footer            -mzscheme          +termresponse
+balloon_eval_term +fork()            +netbeans_intg     +textobjects
-browse            +gettext           +num64             +textprop
++builtin_terms    -hangul_input      +packages          +timers
+byte_offset       +iconv             +path_extra        +title
+channel           +insert_expand     -perl              -toolbar
+cindent           +job               +persistent_undo   +user_commands
+clientserver      +jumplist          +postscript        +vartabs
+clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +virtualedit
+cmdline_hist      +langmap           -python            +visual
+cmdline_info      +libcall           -python3           +visualextra
+comments          +linebreak         +quickfix          +viminfo
+conceal           +lispindent        +reltime           +vreplace
+cryptv            +listcmds          +rightleft         +wildignore
+cscope            +localmap          -ruby              +wildmenu
+cursorbind        -lua               +scrollbind        +windows
+cursorshape       +menu              +signs             +writebackup
+dialog_con        +mksession         +smartindent       +X11
+diff              +modify_fname      -sound             +xfontset
+digraphs          +mouse             +spell             -xim
-dnd               -mouseshape        +startuptime       -xpm
-ebcdic            +mouse_dec         +statusline        +xsmp_interact
+emacs_tags        -mouse_gpm         -sun_workshop      +xterm_clipboard
+eval              -mouse_jsbterm     +syntax            -xterm_save
+ex_extra          +mouse_netterm     +tag_binary
+extra_search      +mouse_sgr         -tag_old_static
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: afl-clang-fast -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: afl-clang-fast   -L/usr/local/lib -Wl,--as-needed -o vim    -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lelf -lnsl  -ldl

MData:
While fuzzing VIM with enabling different mode an use-after-free was observed. This is
likely  a write access violation, which means the attacker may have control over the
write address and value.

GDB BT:
(gdb) run -u NONE -X -Z -e -s -S out/id\:000001\,sig\:11\,src\:018487\,time\:45124324+017124\,op\:splice\,rep\:8 -c ':qa!'
Starting program: /home/input0/nvim/vim/src/vim -u NONE -X -Z -e -s -S out/id\:000001\,sig\:11\,src\:018487\,time\:45124324+017124\,op\:splice\,rep\:8 -c ':qa!'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000041adeb in bt_terminal (buf=0x7ffff6c3fca0 <main_arena+96>) at buffer.c:5307
5307	    return buf != NULL && buf->b_p_bt[0] == 't';
(gdb) bt
#0  0x000000000041adeb in bt_terminal (buf=0x7ffff6c3fca0 <main_arena+96>) at buffer.c:5307
#1  0x00000000008ed15d in win_enter_ext (wp=<optimized out>, undo_sync=<optimized out>, curwin_invalid=0,
    trigger_new_autocmds=<optimized out>, trigger_enter_autocmds=<optimized out>, trigger_leave_autocmds=<optimized out>) at window.c:4658
#2  0x00000000008e8b02 in win_split_ins (size=<optimized out>, flags=<optimized out>, new_wp=<optimized out>, dir=<optimized out>)
    at window.c:1326
#3  0x00000000008e0f1f in win_split (size=0, flags=0) at window.c:812
#4  0x0000000000409e23 in do_argfile (eap=0x7fffffffa890, argn=0) at arglist.c:662
#5  0x00000000005214bd in do_one_cmd (sourcing=<optimized out>, cstack=<optimized out>, cmdlinep=<optimized out>, fgetline=<optimized out>,
    cookie=<optimized out>) at ex_docmd.c:2470
#6  do_cmdline (cmdline=<optimized out>, fgetline=<optimized out>, cookie=<optimized out>, flags=<optimized out>) at ex_docmd.c:966
#7  0x00000000007a0b32 in do_source (fname=<optimized out>, check_other=<optimized out>, is_vimrc=<optimized out>) at scriptfile.c:1214
#8  0x000000000079f5b9 in cmd_source (fname=0xc4f583 "out/id:000001,sig:11,src:018487,time:45124324+017124,op:splice,rep:8",
    eap=<optimized out>) at scriptfile.c:805
#9  0x00000000005214bd in do_one_cmd (sourcing=<optimized out>, cstack=<optimized out>, cmdlinep=<optimized out>, fgetline=<optimized out>,
    cookie=<optimized out>) at ex_docmd.c:2470
#10 do_cmdline (cmdline=<optimized out>, fgetline=<optimized out>, cookie=<optimized out>, flags=<optimized out>) at ex_docmd.c:966
#11 0x000000000096e6c9 in exe_commands (parmp=<optimized out>) at main.c:3133
#12 vim_main2 () at main.c:795
#13 0x000000000096b597 in main (argc=<optimized out>, argv=<optimized out>) at main.c:444
(gdb) i r
rax            0xfffffffffffffffc	-4
rbx            0xc6dae0	13032160
rcx            0x0	0
rdx            0xc27900	12744960
rsi            0x0	0
rdi            0x7ffff6c3fca0	140737333427360
rbp            0xc6dae8	0xc6dae8
rsp            0x7fffffff96c8	0x7fffffff96c8
r8             0x5f	95
r9             0x1	1
r10            0x7fffffff8c60	140737488325728
r11            0x0	0
r12            0x1	1
r13            0x0	0
r14            0xfffffffffffffffc	-4
r15            0x1	1
rip            0x41adeb	0x41adeb <bt_terminal+75>
eflags         0x10206	[ PF IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb)

ASAN BT:
==14666==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500000f108 at pc 0x000000db2301 bp 0x7ffcbdb68e70 sp 0x7ffcbdb68e68
READ of size 8 at 0x62500000f108 thread T0
    #0 0xdb2300 in win_enter_ext /home/input0/vim/src/window.c:4658:25
    #1 0xda89af in win_split_ins /home/input0/vim/src/window.c:1326:5
    #2 0xd9b007 in win_split /home/input0/vim/src/window.c:812:12
    #3 0x516344 in do_argfile /home/input0/vim/src/arglist.c:662:10
    #4 0x7120d0 in do_one_cmd /home/input0/vim/src/ex_docmd.c:2470:2
    #5 0x7120d0 in do_cmdline /home/input0/vim/src/ex_docmd.c:966
    #6 0xb60432 in do_source /home/input0/vim/src/scriptfile.c:1214:5
    #7 0xb5e5bf in cmd_source /home/input0/vim/src/scriptfile.c:805:14
    #8 0x7120d0 in do_one_cmd /home/input0/vim/src/ex_docmd.c:2470:2
    #9 0x7120d0 in do_cmdline /home/input0/vim/src/ex_docmd.c:966
    #10 0xe9998f in exe_commands /home/input0/vim/src/main.c:3133:2
    #11 0xe9998f in vim_main2 /home/input0/vim/src/main.c:795
    #12 0xe94b2c in main /home/input0/vim/src/main.c:444:12
    #13 0x7f32b72bbb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #14 0x41ff49 in _start (/home/input0/vim/src/vim+0x41ff49)

0x62500000f108 is located 8 bytes inside of 8664-byte region [0x62500000f100,0x6250000112d8)
freed by thread T0 here:
    #0 0x4d53e8 in __interceptor_free.localalias.0 (/home/input0/vim/src/vim+0x4d53e8)
    #1 0x8f411e in vim_free /home/input0/vim/src/misc2.c:1802:2
    #2 0x5270ea in apply_autocmds /home/input0/vim/src/autocmd.c:1607:12
    #3 0xda89af in win_split_ins /home/input0/vim/src/window.c:1326:5
    #4 0xd9b007 in win_split /home/input0/vim/src/window.c:812:12

previously allocated by thread T0 here:
    #0 0x4d55a0 in malloc (/home/input0/vim/src/vim+0x4d55a0)
    #1 0x8ef102 in lalloc /home/input0/vim/src/misc2.c:924:11
    #2 0xd9b007 in win_split /home/input0/vim/src/window.c:812:12

SUMMARY: AddressSanitizer: heap-use-after-free /home/input0/vim/src/window.c:4658:25 in win_enter_ext
Shadow bytes around the buggy address:
  0x0c4a7fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff9df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c4a7fff9e20: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff9e30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff9e40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff9e50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff9e60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff9e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==14666==ABORTING

To Reproduce: vim -u NONE -X -Z -e -s -S $POC -c ':qa!'

The reproduction script looks like noise...
Since you compiled with -O2 the stack does not show the exact location of the alloc and free calls.
Can you still reproduce it without -O2?

@brammool  wrote:

The reproduction script looks like noise...
Since you compiled with -O2 the stack does not show the exact location of the alloc and free calls.
Can you still reproduce it without -O2?

I can reproduce the bug with vim-8.1.2135.
I simplified the file that triggers it.
$ cat > bug.vim <<EOF
pedit xx
n x
au * ? ,q
split
EOF

$ ./vim --clean -e -s -S bug.vim
=================================================================
==15150==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500004b108 at pc 0x557763a18df9 bp 0x7ffc7e62d950 sp 0x7ffc7e62d940
READ of size 8 at 0x62500004b108 thread T0
    #0 0x557763a18df8 in win_enter_ext /home/pel/sb/vim/src/window.c:4658
    #1 0x557763a08cc7 in win_split_ins /home/pel/sb/vim/src/window.c:1326
    #2 0x557763a058e8 in win_split /home/pel/sb/vim/src/window.c:812
    #3 0x5577635eec7a in ex_splitview /home/pel/sb/vim/src/ex_docmd.c:5753
    #4 0x5577635dc9b7 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2470
    #5 0x5577635d3ce1 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:966
    #6 0x55776388de72 in do_source /home/pel/sb/vim/src/scriptfile.c:1214
    #7 0x55776388c35e in cmd_source /home/pel/sb/vim/src/scriptfile.c:805
    #8 0x55776388c3cb in ex_source /home/pel/sb/vim/src/scriptfile.c:831
    #9 0x5577635dc9b7 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2470
    #10 0x5577635d3ce1 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:966
    #11 0x5577635d2382 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:567
    #12 0x557763aacb64 in exe_commands /home/pel/sb/vim/src/main.c:3133
    #13 0x557763aa54b4 in vim_main2 /home/pel/sb/vim/src/main.c:795
    #14 0x557763aa4ca7 in main /home/pel/sb/vim/src/main.c:444
    #15 0x7f8ece149b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #16 0x557763474709 in _start (/home/pel/sb/vim/src/vim+0x101709)

0x62500004b108 is located 8 bytes inside of 8664-byte region [0x62500004b100,0x62500004d2d8)
freed by thread T0 here:
    #0 0x7f8ecffcf7b8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7b8)
    #1 0x5577637111de in vim_free /home/pel/sb/vim/src/misc2.c:1802
    #2 0x557763485bda in apply_autocmds_group /home/pel/sb/vim/src/autocmd.c:2168
    #3 0x557763483dd1 in apply_autocmds /home/pel/sb/vim/src/autocmd.c:1607
    #4 0x557763a18cbd in win_enter_ext /home/pel/sb/vim/src/window.c:4645
    #5 0x557763a08cc7 in win_split_ins /home/pel/sb/vim/src/window.c:1326
    #6 0x557763a058e8 in win_split /home/pel/sb/vim/src/window.c:812
    #7 0x5577635eec7a in ex_splitview /home/pel/sb/vim/src/ex_docmd.c:5753
    #8 0x5577635dc9b7 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2470
    #9 0x5577635d3ce1 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:966
    #10 0x55776388de72 in do_source /home/pel/sb/vim/src/scriptfile.c:1214
    #11 0x55776388c35e in cmd_source /home/pel/sb/vim/src/scriptfile.c:805
    #12 0x55776388c3cb in ex_source /home/pel/sb/vim/src/scriptfile.c:831
    #13 0x5577635dc9b7 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2470
    #14 0x5577635d3ce1 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:966
    #15 0x5577635d2382 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:567
    #16 0x557763aacb64 in exe_commands /home/pel/sb/vim/src/main.c:3133
    #17 0x557763aa54b4 in vim_main2 /home/pel/sb/vim/src/main.c:795
    #18 0x557763aa4ca7 in main /home/pel/sb/vim/src/main.c:444
    #19 0x7f8ece149b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

previously allocated by thread T0 here:
    #0 0x7f8ecffcfb50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
    #1 0x55776370ee5f in lalloc /home/pel/sb/vim/src/misc2.c:924
    #2 0x55776370ecf9 in alloc_clear /home/pel/sb/vim/src/misc2.c:851
    #3 0x557763a19575 in win_alloc /home/pel/sb/vim/src/window.c:4752
    #4 0x557763a0700b in win_split_ins /home/pel/sb/vim/src/window.c:1073
    #5 0x557763a058e8 in win_split /home/pel/sb/vim/src/window.c:812
    #6 0x5577635eec7a in ex_splitview /home/pel/sb/vim/src/ex_docmd.c:5753
    #7 0x5577635dc9b7 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2470
    #8 0x5577635d3ce1 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:966
    #9 0x55776388de72 in do_source /home/pel/sb/vim/src/scriptfile.c:1214
    #10 0x55776388c35e in cmd_source /home/pel/sb/vim/src/scriptfile.c:805
    #11 0x55776388c3cb in ex_source /home/pel/sb/vim/src/scriptfile.c:831
    #12 0x5577635dc9b7 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2470
    #13 0x5577635d3ce1 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:966
    #14 0x5577635d2382 in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:567
    #15 0x557763aacb64 in exe_commands /home/pel/sb/vim/src/main.c:3133
    #16 0x557763aa54b4 in vim_main2 /home/pel/sb/vim/src/main.c:795
    #17 0x557763aa4ca7 in main /home/pel/sb/vim/src/main.c:444
    #18 0x7f8ece149b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: heap-use-after-free /home/pel/sb/vim/src/window.c:4658 in win_enter_ext
Shadow bytes around the buggy address:
  0x0c4a800015d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a800015e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a800015f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a80001600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a80001610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c4a80001620: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a80001630: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a80001640: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a80001650: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a80001660: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a80001670: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==15150==ABORTING
Aborted (core dumped)

I have not tried to debug yet, but it's probably a rogue autocommand.

The reproduction script looks like noise...
Since you compiled with -O2 the stack does not show the exact location of the alloc and free calls.
Can you still reproduce it without -O2?

Yes, this can be reproduced without -O2

Dominique wrote:

@brammool  wrote:

The reproduction script looks like noise...
Since you compiled with -O2 the stack does not show the exact location of the alloc and free calls.
Can you still reproduce it without -O2?

I can reproduce the bug with vim-8.1.2135.
I simplified the file that triggers it.
$ cat > bug.vim <<EOF
pedit xx
n x
au * ? ,q
split
EOF

Thanks.  From the stack I can see what happens: the autocommand closes
the window and "wp" is used after that.
I added the example to a test, but valgrind doesn't see the problem.
Changing it a bit does reproduce it.
--
BRIDGEKEEPER: What is your favorite editor?
GAWAIN:       Emacs ...  No, Viiiiiiiiiiimmmmmmm!
"Monty Python and the Holy editor wars" PYTHON (MONTY) SOFTWARE LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

authors: RootUp brammool dpelle


text:
Vim9: setwinvar() does not take true as third argument

Describe the bug
In Vim9 script, we cannot use setwinvar() to set a boolean window-local option.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    setwinvar(win_getid(), '&number', true)
EOF
)

E1138 is raised:
E1138: Using a Bool as a Number

Expected behavior
No error is raised because 'number' is a boolean option, and true is a boolean value.
Environment

Vim version: 8.2 Included patches: 1-2269
OS: Ubuntu 16.04.7 LTS
Terminal: xterm(363)

Additional context
Regression introduced in 8.2.1465.

Same issue with setbufvar():
vim9script
setbufvar(bufnr(), '&autoindent', true)

E1138: Using a Bool as a Number

And settabwinvar():
vim9script
settabwinvar(1, 1, '&list', true)

E1138: Using a Bool as a Number

No error in Vim script legacy:
call setwinvar(win_getid(), '&number', v:true)

Patch adding a test:
diff --git a/src/testdir/test_vim9_builtin.vim b/src/testdir/test_vim9_builtin.vim
index accbca237..3fb2fb088 100644
--- a/src/testdir/test_vim9_builtin.vim
+++ b/src/testdir/test_vim9_builtin.vim
@@ -601,11 +601,15 @@ def Test_setbufvar()
   &syntax->assert_equal('vim')
   setbufvar(bufnr('%'), '&ts', 16)
   &ts->assert_equal(16)
+  setbufvar(bufnr('%'), '&ai', true)
+  &ai->assert_equal(true)
   settabwinvar(1, 1, '&syntax', 'vam')
   &syntax->assert_equal('vam')
   settabwinvar(1, 1, '&ts', 15)
   &ts->assert_equal(15)
-  setlocal ts=8
+  settabwinvar(1, 1, '&list', true)
+  &list->assert_equal(true)
+  setlocal ts=8 noai nolist

   setbufvar('%', 'myvar', 123)
   getbufvar('%', 'myvar')->assert_equal(123)

The issue persists when setwinvar() receives its value from getwinvar():
vim9
var id = win_getid()
getwinvar(id, '&number')->setwinvar(id, '&number')

E521: Number required: &number = 'false'

Which is weird, considering that getwinvar() outputs a boolean number, and that replacing getwinvar() with a boolean number doesn't raise any error:
vim9
var id = win_getid()
eval 0->setwinvar(id, '&number')

✔

vim9
var id = win_getid()
eval 1->setwinvar(id, '&number')

✔

Same issue in a :def function:
vim9
def Func()
    var id = win_getid()
    getwinvar(id, '&number')->setwinvar(id, '&number')
enddef
Func()

E521: Number required: &number = 'false'

The issue persists when setwinvar() receives its value from getwinvar():
vim9
var id = win_getid()
getwinvar(id, '&number')->setwinvar(id, '&number')

E521: Number required: &number = 'false'

Which is weird, considering that getwinvar() outputs a boolean number, and that replacing getwinvar() with a boolean number doesn't raise any error:
vim9
var id = win_getid()
eval 0->setwinvar(id, '&number')

✔

vim9
var id = win_getid()
eval 1->setwinvar(id, '&number')

✔

Same issue in a :def function:
vim9
def Func()
    var id = win_getid()
    getwinvar(id, '&number')->setwinvar(id, '&number')
enddef
Func()

E521: Number required: &number = 'false'

Strangely, it only happens when 'number' is not set.

Strangely, it only happens when 'number' is not set.

source: gharchive/issue

authors: brammool lacygoill

repo: vim/vim

license: Vim

license_type: permissive

license_source: github-api


text:
win32,python3: Load DLL from registry path

Support loading python3.dll and/or python3xx.dll from the path written in the registry.  To support Stable ABI's forwarder DLL (python3.dll), use the LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR flag for LoadLibraryEx().
If Stable ABI is used, search the latest version from the registry (both from HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE).  If Stable ABI is not used, search only the matching version.

thanks!

source: gharchive/pull-request

authors: chrisbra k-takata


text:
Improve parsing of Urxvt and SGR mouse escape codes.

Urxvt mouse escape codes look like this: ESC[35;123;321M
When ttymouse=urxvt, <UrxvtMouse> would be set to only ESC[, and
then some logic later in check_termcode would react to that, and parse
the rest of the data after it. However, ESC[ is also the prefix of some
other escape codes, like <zHome> (ESC[8~). So, those would stop
working when ttymouse=urxvt, as they are then read as <UrxvtMouse>8~.
This patch changes <UrxvtMouse> to not match just ESC[, but match the
full escape code: ESC[*M, where the asterisk is a wildcard. Such a
'wildcard' functionality was already available for ;*X and <M-O>*X,
and is now extended to work for any *X. This way, the <UrxvtMouse>
escape code is no longer a prefix of other escape codes. The logic in
check_termcode parsing the mouse commands is changed accordingly.
This patch does the same for <SgrMouse>, for ttymouse=sgr. However, SGR
mouse escape codes for release events end in m, instead of M. Now
the full escape code is matched, instead of just the ESC[ prefix, these
different escape codes now have different keys in keymap.h: <SgrMouse>
and <SgrMouseRel>.
Tested in Urxvt v9.22 with ttymouse=urxvt, and in Xterm 327 with
ttymouse=sgr.

Tested on Archlinux with urxvt 9.22 and vim 8.0.0628, works fine. Thanks for the patch!

authors: Narthorn m-ou-se


text:
Improve test coverage of rename()

This PR improves test coverage of function rename().

Codecov Report

Merging #4061 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4061      +/-   ##
==========================================
+ Coverage   79.19%    79.2%   +0.01%
==========================================
  Files         105      105
  Lines      141143   141143
==========================================
+ Hits       111775   111797      +22
+ Misses      29368    29346      -22

Impacted Files
Coverage Δ

src/gui_beval.c
61.57% <0%> (-0.88%)
:arrow_down:

src/if_xcmdsrv.c
83.48% <0%> (-0.36%)
:arrow_down:

src/gui.c
58.1% <0%> (-0.21%)
:arrow_down:

src/gui_gtk_x11.c
48.37% <0%> (-0.2%)
:arrow_down:

src/sign.c
93.38% <0%> (-0.13%)
:arrow_down:

src/ex_cmds2.c
84.89% <0%> (-0.1%)
:arrow_down:

src/window.c
83.51% <0%> (-0.04%)
:arrow_down:

src/terminal.c
79.04% <0%> (ø)
:arrow_up:

src/ui.c
50.22% <0%> (+0.07%)
:arrow_up:

src/ex_cmds.c
81.72% <0%> (+0.09%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ab350f8...9dedb26. Read the comment docs.

authors: codecov-io dpelle


text:
Spacing difference between index and post/page

The space between the title and image is different on the index page compared to the post/page.  It should be the same.

Solved by using common title fragment.  Will be merged into develop

repo: vindevoy/cherryblog

license: MIT


text:
bug

Closed for now as can not reproduce

repo: vinhnx/Clendar


text:
Request for an event

Please provide the following information

Is this event for college students or professionals?

How many folks do you expect will attend this event? 100-130

When do you want this event? 02.10.2021 and 03.10.2021

Language of the event? English and Telugu

[x] fill this google form.

@himabindu-run can you please share your community name?

Google Developer Students Club GVP Chapter

Received , will be reaching out soon
Thanks


text:
added the relay nostrhackers.online, with alias: nostrhackers

Added the relay wss://relay.nostrhackers.online , with alias nostrhackers

Thank you!

authors: KonstantinosNikolakakis vinliao

repo: vinliao/nashboard


text:
Windows support

Hi again!
Wanted to bring to your attention that I think hot-esm doesn't work on Windows. I recently disabled hot-esm in my project because it was causing issues.
I think it has something to do with paths on windows but I didn't get a chance to look into it too much -- just raising it to you in case you have some time to look into it!

Hi @hpx7! Sorry for the delay; I was pretty swamped this week.
I'm on it! I've always wanted to figure out how to develop/test for Windows. I'll try to track it down and let you know what I find!
From the bit of code you linked to, I'm guessing that you're supporting TypeScript for your users by way of ts-node. Hopefully, hot-esm is playing nice with that loader. Let me know if you find any weird interactions.

Thanks @vinsonchuong! You can try getting a Windows VM on Azure for testing purposes.
Yup the loaders are working great with each other, although it was a pain to set up initially.

Hey @vinsonchuong have you had a chance to look into this at all?

@hpx7 Apologies for the delay. Work has been occupying me more than I'd like...
I have been looking into this whenever I can find the time.
It took forever to figure out how to do performant virtualization of Windows 11. I figured it out though. I foresee that I'll probably be spending more time writing code in the Windows VM as I find issues in my packages.
I do have failing unit tests for hot-esm in Windows, both in the PowerShell and WSL.
My plan is to first build support for the WSL as that seems like it will take the least work.
Then, I'll see how to make it all run in a regular PowerShell. I suspect that I may have to add Windows support to some of my other packages to hit this goal...
@hpx7, do you insights into how you or your Windows users like to run Node.js code? Whether WSL is popular, or Cygwin, or MinGW? I'm a bit out of touch with development on Windows these days.

Glad to hear that you were able to get a repro!
I believe most users are using WSL

@hpx7, I've gotten some learnings.
I'm currently using ArchWSL instead of Ubuntu, mainly just to be able to easily get the latest versions of different packages. But, I don't think this should cause differences in behavior.
hot-esm seems to work fine as long as the code is inside of the Linux file system, e.g. /root/project. It definitely does not work when the code is in C:\, e.g. /mnt/c/Users/vinson/project.
I traced it to this issue against WSL. Because of this, Chokidar is unable to efficiently watch for file updates using inotify. I can recover the functionality by telling Chokidar to poll instead. I'm not sure what the performance implications are though.

Hey @vinsonchuong, wanted to check in and see if you've had time to investigate this any further?

Hey @hpx7, sorry for dropping the loop on this.
For Windows users, if their codebase is located in the "native" Linux file system, file watching should work. (Let me know if that's not what you're seeing). I'd suggest doing this if possible.
But, if it's elsewhere, like on the C:\ drive, our only recourse is to poll each file that we want to watch.
I've figured out how to get metadata on the file system, so, I could automatically switch to polling if I know inotify isn't going to work.
I could also instead allow an environment variable to be set to force polling.
Do you have thoughts on which one you'd like to see?

@vinsonchuong there are indeed users with projects on the C:\ drive who are running into this issue. I think the automatic switch to polling would be best. I'm not too concerned about performance, but I can provide timely feedback via my users on how well a solution works for them.

@hpx7, I've released a fix in version 1.5.0.
In WSL, when watching files that live in 9P mounts, like C:\, we automatically switch to polling. I've only tested this in Windows 11 so far.
Let me know if you notice anything amiss.

repo: vinsonchuong/hot-esm


text:
Styling causes Chrome white-space-below-body white issue

This styling in the component caused for me the dreaded Chrome-only "white-space-below-body" issue.
input {

    position: absolute !important;
    height: 1px;
    width: 1px;
    overflow: hidden;
    clip: rect(1px 1px 1px 1px);
    clip: rect(1px, 1px, 1px, 1px);
    white-space: nowrap;
  }

As a work-around I've surrounded my <FileUpload  ... > in a div with position:relative and the problem is gone.
However, perhaps instead the input could just be:
input {
   display: none;
}

That works for my case but not sure of the impact for others.

I'll have to look into it, the problem is screen reader expectations. If display: none; is used its unselectable for screen readers (and drag dropping may be difficult if not impossible for the visually impaired). Whereas the current style is supposed to work for screen readers but not affect other content (though obviously it does as it adds the white space below body nonsense).


text:
Any Way to get facebook video URL?

Hi @viralvaghela  Thanks for this plugin
need to ask if there is any similar implementation for facebook as well

Hi @gauravmehta13 Thanks, Not sure about facebook, I have to check!


text:
Fedora 38 compose Fedora-38-20230413.1 iot-installer-f38 issue: deployed ostree ref failed

Our CI has detected failures in iot-installer-f38 compose Fedora-38-20230413.1
TASK [assert] ******************************************************************
fatal: [192.168.100.50]: FAILED! => changed=false
  assertion: result_ref.stdout == ostree_ref
  evaluated_to: false
  msg: deployed ostree ref failed

TASK [assert] ******************************************************************
fatal: [192.168.100.50]: FAILED! => changed=false
  assertion: result_var_mount_point.stdout == "/dev/vda2[/ostree/deploy/fedora/var]"
  evaluated_to: false
  msg: /var does not mount on /dev/vda2[/ostree/deploy/fedora/var]

This is likely happening because the ostree_ref variable has changed from fedora to fedora-iot
The solution is to update ostree_ref value in ostree-ng.sh test case. I will provide a soon a PR for this issue.

A suggested workaround has been merged into main.
In case similar issues appear in f39, f40, etc. a similar workaround will be applied.


text:
Fixes a crash, if you stop discovery.

If, you cancel discovery the clientUdpClient is set to null.
However, nothing cancels ClientListenAsync. If we change the if(true) to check if the client is null. You can properly cancel the discovery, and kill the listen thread.

Also, if you cancel the discovery search. It crashes the thread, and is super noisy in the output.

Nice find. This will probably be useful in LTS as well, since the crash is likely present there too.
Just to keep vis happy, can you tell us how to trigger this step by step before applying the fix?

authors: Clancey SoftwareGuy


text:
add(examples) basic basemap example

Simplified version of the trips example for a getting started guide.

Pull Request Test Coverage Report for Build 1401196487

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 26.037%

Totals

Change from base Build 1401176577:
0.0%

Covered Lines:
231

Relevant Lines:
773

💛  - Coveralls

authors: chrisgervang coveralls


text:
CX Second_Order_SQL_Injection @ website/include/comments.php [master]

Second_Order_SQL_Injection issue exists @ website/include/comments.php in branch master
Method add_comment at line 48 of website\include\comments.php gets database data from the mysql_fetch_assoc element. This element’s value then flows through the code without being properly sanitized or validated, and is eventually used in a database query in method add_comment at line 48 of website\include\comments.php. This may enable an Second-Order SQL Injection attack.
Severity: High
CWE:89
Vulnerability details and guidance
Checkmarx
Lines: 60

Code (Line #60):
      $preview = mysql_fetch_assoc($res);

Issue still exists.

Issue still exists.


text:
Github releases for stable versions

Hello once more! It looks like SealNote has been accepted into the F-Droid repo, but they were curious about the addition of stable version tags.
It's an argument of ease for the maintainers, as it appears that someone will have to push new versions of the app to F-Droid manually if tagged releases are not present. Would you be interested in releasing in such a fashion?
Once more, thank you for your quick and kindly replies to these matters!

Sure, we can do tagged releases. How does F-droid do ordering of tags, using dates or the tag name itself?

Judging from this documentation, F-Droid just requires releases tagged with the version number. So, only the tag name itself, if I'm gathering this correctly!

Pushed first tag v0.8.7

authors: chadcurtis vishesh

repo: vishesh/sealnote

license: mit

license_source: bigquery


text:
When test fails in async callback it aborts other tests

describe('mocha tests', function() {
    it('should go to the next test when it fails (outside callback)', function(done){
        throw new Error('the other test should still run');
        done();
    });

    it('should go to the next test when it fails (inside callback)', function(done) {

        setTimeout(function() {
            throw new Error('the other test should still run');
            done();
        }, 0);
    });

    it('should get to this test', function(done) {
        done();
    });
});

I expect that it should run all the tests and report 2 failures and 1 success. Instead I get this (only 2 out of 3 tests were run):
mocha ./test/test.test.js

  ..

  ✖ 2 of 3 tests failed:

  0) mocha tests should go to the next test when it fails (outside callback):
     Error: the other test should still run

  at Test.fn (/Users/me/mochatest/test/test.test.js:3:19)
      at Test.run (/usr/local/lib/node_modules/mocha/lib/runnable.js:103:12)
      at Runner.runTest (/usr/local/lib/node_modules/mocha/lib/runner.js:244:10)
      at /usr/local/lib/node_modules/mocha/lib/runner.js:290:12
      at next (/usr/local/lib/node_modules/mocha/lib/runner.js:172:14)
      at /usr/local/lib/node_modules/mocha/lib/runner.js:181:7
      at next (/usr/local/lib/node_modules/mocha/lib/runner.js:133:23)
      at Array.0 (/usr/local/lib/node_modules/mocha/lib/runner.js:149:5)
      at EventEmitter._tickCallback (node.js:192:40)

  1) mocha tests should go to the next test when it fails:
     Error: the other test should still run

  at Timer.ontimeout (/Users/me/mochatest/test/test.test.js:10:23)

This is the same if I'm running multiple files.

yeah I'll see if I can fix that, the tricky thing is handling stuff like:
  it('should bar', function(done){
    process.nextTick(function(){
      done();
      setTimeout(function(){
        throw new Error('fail in bar');
      }, 100);
    });
  })

  it('should baz', function(done){
    setTimeout(function(){
      done();
    }, 1000);
  })

that will map it to baz

nvm seems fine for me:
  it('should fail', function(done){
    process.nextTick(function(){
      'foo'.should.equal('bar');
    });
  })

outputs:

  ✖ 1 of 47 tests failed:

  0) global leaks should fail:
     AssertionError: expected 'foo' to equal 'bar'
      at Object.equal (/Users/tj/Projects/mocha/node_modules/should/lib/should.js:306:10)
      at Array.<anonymous> (/Users/tj/Projects/mocha/test/globals.js:33:20)
      at EventEmitter._tickCallback (node.js:126:26)

Does it actually run the other tests?
it('should fail', function(done){
   process.nextTick(function(){
      'foo'.should.equal('bar');
  });
});

it('should fail too', function(done){
   should.fail('fail');
});

it('should pass', function(done){
   done();
});

$:mochatest pselden$ mocha test.js -r should

  .

  ✖ 1 of 3 tests failed:

  0)  should fail:
     AssertionError: expected 'foo' to equal 'bar'
      at Object.equal (/usr/local/lib/node_modules/should/lib/should.js:306:10)
      at Array.0 (/Users/pselden/Documents/mochatest/test.js:3:20)
      at EventEmitter._tickCallback (node.js:192:40)

It should be two failures but the other one isn't run. I just upgraded to 0.2.0 to check if that was it but still doesn't work. If you can't reproduce with that test case then I will dig in and start debugging.

we need to tweak https://github.com/visionmedia/mocha/blob/master/lib/runner.js#L369 removing "end", clear the timer and continue on

I experience this problem with mocha 2.2.5.

Same on 2.3.3

The issue highlighted in https://github.com/mochajs/mocha/issues/94#issuecomment-2969601 is not a problem in 2.3.4. Note that both failures are reported, rather than only 1 in the prior example.
$ mocha --version
2.3.4
danielstjules:~/Desktop

$ cat test.js
var assert = require('assert');

it('should fail', function(done){
   process.nextTick(function() {
      assert(false);
  });
});

it('should fail too', function(done){
   assert(false);
});

it('should pass', function(done){
   done();
});

danielstjules:~/Desktop
$ mocha test.js

  1) should fail
  2) should fail too
  ✓ should pass

  1 passing (12ms)
  2 failing

  1)  should fail:

      Uncaught AssertionError: false == true
      + expected - actual

      -false
      +true

      at test.js:5:7

  2)  should fail too:

      AssertionError: false == true
      + expected - actual

      -false
      +true

      at Context.<anonymous> (test.js:10:4)

same on 6.0.2
$ ./node_modules/mocha/bin/mocha --version 6.0.2

authors: alex-di artem-karpenko danielstjules pselden4 rawqing visionmedia

repo: visionmedia/mocha


text:
Update redirects

Rebased off master and resolved conflicts

LGTM :+1:

authors: focusaurus olalonde

repo: visionmedia/superagent


text:
VisIt can't connect client/server to sims when ssh tunneling is on.

VisIt isn't successfully connecting client/server to sims when ssh tunneling is on. It works when ssh tunneling is off. However, when tunneling is on, the connection seems to be made but the type representations read in the sim contains all zeros. Maybe the socket bridge in vcl is to blame? This is happening on the trunk but I think I have also seen it in released versions of VisIt.
-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.
Ticket number: 1193
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: VisIt can't connect client/server to sims when ssh tunneling is on.
Assigned to: Brad Whitlock
Category: -
Target version: 2.7
Author: Brad Whitlock
Start: 09/06/2012
Due date:
% Done: 100%
Estimated time:
Created: 09/06/2012 08:33 pm
Updated: 08/20/2013 03:13 pm
Likelihood: 3 - Occasional
Severity: 3 - Major Irritation
Found in version: 2.5.2
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
VisIt isn't successfully connecting client/server to sims when ssh tunneling is on. It works when ssh tunneling is off. However, when tunneling is on, the connection seems to be made but the type representations read in the sim contains all zeros. Maybe the socket bridge in vcl is to blame? This is happening on the trunk but I think I have also seen it in released versions of VisIt.
Comments:
We've recently upgraded from VisIt 2.5.2 to 2.6.0, and are having sometrouble connecting to instrumented simulations. We're able to reproducethe problem with a simple test program (included below, with log fromdebug 5 run), and it looks like a socket issue. We've already done all ofthe troubleshooting we could think of on our firewall settings, and hopethat maybe someone could help us here.Here's a walk through of what we see: We launch the simulation (compiledfrom the code below) on a linux node, and it starts normally. It creates asim2 file in ~/.visit/simulations with what I would expect are propersettings, the name of the node, the port, etc. And we have it set toblocking, so it waits for an incoming connection.At this point, we start VisIt 2.6.0 on Windows (with debug 5 to get somedebug info) click open, select the linux host entry in the connectionwindow, which starts qssh (prompts me for my password), which launches themetadata server. I browse to the file location(~/.visit/simulation/.sim2), and open the file.On the linux side, the libsim V2 code attempts to create 1 read and 3write sockets, with the first two connections working, and the next twoconnections refused. It then uses the first (read) socket to query theversion of the windows client. It's at this point that the recv functionfails (returns 1), but no error condition is generated yet. Shortlyafter, the code attempts to get the version of the windows client from thestillempty buffer, and this evaluates to a blank version string. Whenit's compared to 2.6.0 local (linux) version string, it causes theversion check to fail and an exception to be generated. The resultingerror is written to the log A.visit.5.vlog and the program exits with:Versions are (),2.6.0Exception: (IncompatibleVersionException)On the desktop side, the "compute engine launch progress" windows is stillwaiting, and has to be cancelled.Some questions we have are: what are the 1 'read' and '3' write socketsused for? Also, why would some of the sockets (first read and first write)connect, while the others have connection refused? It looks like even theconnected read socket has a problem, as the 'recv' called on it returns1, leaving the zeroedout buffer unaltered.The comments in the logs says that 9/10 of the issues are with firewalland host file config. What is the ideal setup in the /etc/hosts file?(should the hostname be listed with the 127.0.01 address? should itresolve itself to the actual IP of the first interface?Here is the sample code we used (condensed purposely):#include "VisItControlInterface_V2.h"#include #include <stdlib.h>int main( int argc, char argv[] ) {And the associated log:0visit v 2.6 engine debuglaunch noloopback host node01 port 39879key 89ea67c1a29831b2aa9dENGINE started. pid: 17154ParentProcess::Connect: Called with (numRead=1, numWrite=3, argc=14,argv={visit, v, 2.6, engine, debuglaunch, noloopback, host, node01,port, 39879, key, 89ea67c1a29831b2aa9d, key, 89ea67c1a29831b2aa9d})ParentProcess::Connect: hostName = node01ParentProcess::GetHostInfo: Calling gethostbyname("node-01")ParentProcess::Connect: port = 39879ParentProcess::Connect: securityKey = 89ea67c1a29831b2aa9dParentProcess::Connect: securityKey = 89ea67c1a29831b2aa9dParentProcess::Connect: Creating socketsParentProcess::Connect: Creating read socketsParentProcess::GetClientSocketDescriptor: Set up using port 39879ParentProcess::GetClientSocketDescriptor: Creating a socketParentProcess::GetClientSocketDescriptor: Setting socket optionsParentProcess::GetClientSocketDescriptor: Calling connect(If you see no messages after this one, VisIt was notable to connect to the client machine. Nine times outof ten, this is a firewall issue on the client machine.It could also mean that VisIt was unable to resolve theIP address for the client machine. You may need to verify the contents of/etc/hosts.)ParentProcess::GetClientSocketDescriptor: Connected socketParentProcess::Connect: Creating write socketsParentProcess::GetClientSocketDescriptor: Set up using port 39879ParentProcess::GetClientSocketDescriptor: Creating a socketParentProcess::GetClientSocketDescriptor: Setting socket optionsParentProcess::GetClientSocketDescriptor: Calling connect(If you see no messages after this one, VisIt was notable to connect to the client machine. Nine times outof ten, this is a firewall issue on the client machine.It could also mean that VisIt was unable to resolve theIP address for the client machine. You may need to verify the contents of/etc/hosts.)ParentProcess::GetClientSocketDescriptor: Connected socketParentProcess::GetClientSocketDescriptor: Set up using port 39879ParentProcess::GetClientSocketDescriptor: Creating a socketParentProcess::GetClientSocketDescriptor: Setting socket optionsParentProcess::GetClientSocketDescriptor: Calling connect(If you see no messages after this one, VisIt was notable to connect to the client machine. Nine times outof ten, this is a firewall issue on the client machine.It could also mean that VisIt was unable to resolve theIP address for the client machine. You may need to verify the contents of/etc/hosts.)ParentProcess::GetClientSocketDescriptor: Could not connect! (error=111:Connection refused)ParentProcess::GetClientSocketDescriptor: Set up using port 39879ParentProcess::GetClientSocketDescriptor: Creating a socketParentProcess::GetClientSocketDescriptor: Setting socket optionsParentProcess::GetClientSocketDescriptor: Calling connect(If you see no messages after this one, VisIt was notable to connect to the client machine. Nine times outof ten, this is a firewall issue on the client machine.It could also mean that VisIt was unable to resolve theIP address for the client machine. You may need to verify the contents of/etc/hosts.)ParentProcess::GetClientSocketDescriptor: Could not connect! (error=111:Connection refused)ParentProcess::Connect: Exchanging type representations.Versions are (),2.6.0Exception: (IncompatibleVersionException)/root/visit_2_6_0/visit2.6.0/src/common/comm/CommunicationHeader.C, line270: catch(IncompatibleVersionException)/root/visit_2_6_0/visit2.6.0/src/common/comm/ParentProcess.C:477Exception: (IncompatibleVersionException)/root/visit_2_6_0/visit2.6.0/src/common/comm/ParentProcess.C, line 510:catch(IncompatibleVersionException)/root/visit_2_6_0/visit2.6.0/src/engine/main/Engine.C:1354The engine has a different version than its client. More information from William T Jones.I am using VisIt 2.6.2 to connect a client on my Linux desktop to aremote server through a login node via SSH tunneling. While I can runVisIt in parallel (via PBS) to view files just fine, I am gettingwrapped around the axle with problems connecting to a libsiminstrumented simulation. I cannot connect even to the simplest serialsimulation application which I found on this list (source included withthe logs).Basically: I start the test simulation on the remote machine; fire upVisIt on my desktop; Open a source; select the remote host; navigate tothe sim file in ".visit/simulations" of the remote host; wait forconnection and eventually Cancel. The simple simulation execution lookslike:% ./VisItSimTestWaiting for connection from VisItVisIt did not connect to simulation to exitqI have tried running the simple simulation on the login node as well ason a compute node of the server. The attached "login_logs.tgz" containslogs from running simulation directly on the login server. The attached"node_logs.tgz" contains logs from running on a compute node. Each hasthree directories: "client/" contains the logs from the client;"server/" contains the logs from the server; "sim/" contains the logsfrom the test simulation.I am sure this is a firewall or host table issue, but I cannot figure itout and am somewhat unclear as to the exact process involved. I guessthat VisIt uses the vcl processes to launch things on the remoteserver, but I am unsure as to how the tunneling is supposed to work(e.g. Client tunnels to login node who forwards on to compute nodes).It appears that the simulation does not get the "-sshtunneling" CLO, butI don't know if it needs it by then.Any help would be appreciated. I fixed the order of some calls in the viewer's code that launches the sim via vcl.

1201_login_logs.tgz.zip
Uploading 1201_node_logs.tgz.zip…

1201_login_logs.tgz.zip
1201_node_logs.tgz.zip

repo: visit-dav/visit


text:
build_visit failure on RZ related to pygments

build_visit invocation on the develop branch as of 02/01 morning (after https://github.com/visit-dav/visit/commit/20b72c0a5243fb29b6c3209d8e1616fa4801cfc7):
./build_visit --makeflags -j24 --mesagl --mpich --no-gdal --required --optional --qt6

Cmd line error:
Building VisIt (~50 minutes)
Building VisIt in visit/build . . .
Configuring VisIt . . .
Building VisIt . . . (~50 minutes)
Building the VisIt manuals failed. Continuing
All indications are that VisIt was successfully built.
Packaging VisIt ... (~10 minutes)
VisIt package failed. Giving up
Unable to build or install VisIt. Bailing out.
Error in build process. See build_visit_log for more information. If the error is unclear, please include build_visit_log and contact the VisIt project via https://visit-help.llnl.gov. You may need to compress the build_visit_log using a program like gzip so it will fit within the size limits for attachments.
Log file full path:  /usr/workspace/justin/visit_builds/develop-w-tpls/build_visit_log

From the log:
gmake[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
Traceback (most recent call last):
  File "/usr/workspace/justin/visit_builds/develop-w-tpls/third_party/python/3.9.18/linux-x86_64_gcc-10.3/bin/sphinx-build", line 5, in <module>
    from sphinx.cmd.build import main
  File "/usr/workspace/justin/visit_builds/develop-w-tpls/third_party/python/3.9.18/linux-x86_64_gcc-10.3/lib/python3.9/site-packages/sphinx/cmd/build.py", line 20, in <module>
    from sphinx.application import Sphinx
  File "/usr/workspace/justin/visit_builds/develop-w-tpls/third_party/python/3.9.18/linux-x86_64_gcc-10.3/lib/python3.9/site-packages/sphinx/application.py", line 21, in <module>
    from pygments.lexer import Lexer
ModuleNotFoundError: No module named 'pygments'
make[4]: *** [doc/CMakeFiles/manuals.dir/build.make:70: doc/CMakeFiles/manuals] Error 1
make[3]: *** [CMakeFiles/Makefile2:88735: doc/CMakeFiles/manuals.dir/all] Error 2
make[2]: *** [CMakeFiles/Makefile2:88742: doc/CMakeFiles/manuals.dir/rule] Error 2
gmake[1]: *** [Makefile:187: doc/CMakeFiles/manuals.dir/rule] Error 2
CMake Error at /usr/workspace/justin/visit_builds/develop-w-tpls/visit/build/doc/cmake_install.cmake:51 (file):
  file INSTALL cannot find
  "/usr/workspace/justin/visit_builds/develop-w-tpls/visit/build/resources/help/en_US/manual":
  No such file or directory.
Call Stack (most recent call first):
  /usr/workspace/justin/visit_builds/develop-w-tpls/visit/build/cmake_install.cmake:2692 (include)

CPack Error: Error when generating package: visit
make: *** [Makefile:71: package] Error 1

I saw the same thing on pascal, discovered pygments, applehelp and html help didn't get installed.
Had to reduce the 'pip install' command to the following to get it to work for those packages.
python3 -m pip install –no-deps

I wonder if this is related to: #19279

Here's the messages when you build pygments with the current bv_python.sh and it's arguments to pip install:
pascal83{kbonnell}:../third_party/python/3.9.18/linux-x86_64_gcc-10.3/bin/python3 -m pip --no-cache-dir --disable-pip-version-check install --no-index --no-deps --no-build-isolation .
Processing /usr/WS1/kbonnell/BuildVisIt/3.4.1/Pygments-2.15.1
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: UNKNOWN
  Building wheel for UNKNOWN (pyproject.toml) ... done
  Created wheel for UNKNOWN: filename=UNKNOWN-0.0.0-py3-none-any.whl size=6698 sha256=35e02841eb6a31eaf4ac83af918b98a9739ed4a6998124abaa2ead19ceb511db
  Stored in directory: /tmp/kbonnell/pip-ephem-wheel-cache-8pxgbkvr/wheels/e9/96/ed/eb459de6ab8430acc65b9c96990ed5b0f256a747c1c965131f
Successfully built UNKNOWN
Installing collected packages: UNKNOWN
  Attempting uninstall: UNKNOWN
    Found existing installation: UNKNOWN 0.0.0
    Uninstalling UNKNOWN-0.0.0:
      Successfully uninstalled UNKNOWN-0.0.0
Successfully installed UNKNOWN-0.0.0
pascal83{kbonnell}:

So there is no Pygments in the site-packages of the python install, there is UNKNOWN instead.
This also happens for sphinxcontrib-applehelp-1.0.4 and `sphinxcontrib-htmlhelp-2.0.11

I am still seeing this error on the latest version of the RC (as of 02/12/24).

I am still seeing this error on the latest version of the RC (as of 02/12/24).

Me too. I thought it was because I had an issue in numpy install and restarted the install in the middle of python world magic.

Tried google, came across this:
https://github.com/pypa/setuptools/issues/3269
Seems a problem with setuptools?  but bv_python no longer installs ?
Pygment's pyproject.toml says it requires setuptools:
[build-system]
# setuptools added pyproject.toml support in v61.0.0
requires = ["setuptools >= 61"]

I ran python3 -m pip debug from a build of python 3.9.18 I did locally, and setuptools information from pip was:
 setuptools==44.0.0 (Unable to locate actual module version, using vendor.txt specified version)

I can try adding setuptools to bv_python and see if it resolves this problem.

sorry - sounds like another error due to too many moving pieces.
We should add setuptools back.

I saw a setuptools version 58 in the python site-packages, But that isn't new enough for Pygments.
Pillow's requirement is newer, 67.8, so I will try that one.

@biagas
We should install setuptools at the start, right around where we install wheel
https://github.com/visit-dav/visit/blob/17511b9f1974551dfddbc94268b4bf71d9442334/src/tools/dev/scripts/bv_support/bv_python.sh#L1585

Is there a way to test if a specific version of a module is installed?
I added setuptools before wheel, but 58.0 version is already installed so
check_if_py_module_installed "setuptools" inidicates already installed, and 67.8 doesn't get installed.

ahh -- python has a built in version, maybe we should move the logic for setuptools to where we compile/install python itself and skip the version check since its more of a special case.

setuptools requires wheel, so needs to come after that. I can simply remove the install check, unless you think wheel should also be put into build_python function (?)

we can move wheel there as well. without them both we don't have a solid setup to install other modules

How do the modules without URL's get downloaded?
setuptools isn't getting downloaded, I have to do it manually.

FYI, I did manage to confirm that installing setuptools 67.8.0 as part of bv_python fixes the installation problems with Pygments, sphinxcontrib-applehelp and sphincontrib-htmlhelp.

they should all be reaching back to our copy in github in the visit thirdpary repo.

they should all be reaching back to our copy in github in the visit thirdpary repo.

Aha. I haven't added setuptools there yet, so makes sense.

I'm putting this in 3.4.1 since I cannot build VisIt at all on LC.

authors: JustinPrivitera biagas cyrush markcmiller86


text:
visit 3.2.0 very slow compared to 3.1.4

I am using rhel7 x86_64 versions on Linux Fedora 33 and 34. I have a silo file to use as a test case. Using 3.1.4 after drawing the density the axis can be rotated with mouse very fast and smooth. With 3.2.0 doing the same thing is extremely slow.
I am attaching the silo file here. Steps to reproduce:

Start visit
Open to load fusion_fission.silo
Add--> Volume-->rhotot
Draw
Try to rotate the plot

fusion_fission.silo.gz

Hmmm....I haven't looked yet but am wondering if we maybe got software rendering in there by accident?

Sorry for the confusion. When rhel7 gave black screen I tried the fc31 version. Hopefully it is something easy to fix. Thanks!

I tested the rhel7 version that supports hardware accelerated rendering on my Linux desktop and I got a black screen as well. Since 3.1.4 works with hardware rendering and 3.2.0, it must be related to some difference in the packages between them.
Both user VTK 8.1, so that can be it.
Differences I can think of are:
CMake went from 3.9.3 to 3.14.7.
Qt went from 5.10.1 to 5.14.2.
GCC went from 4.8 to 9.1.
I went and recompiled all the third party libraries and VisIt using CMake 3.9.3 and still got a black screen.

Here is a comment from @biagas with her thoughts on the issue:
We did change Qt versions, and our render windows are a Qt-vtk combo, so that may have something to do with it.
Perhaps we can search our bug tickets for ‘black window’, this may have occurred last time we updated qt (it sounds familiar anyway).  It may be a new flag is needed for the QT build, or to be set when creating the window.

Try removing the -xcb-native-painting flag when building QT. It was added with this PR

it is disappointing that this is delayed! Could we at least have some test build for rhel that has hardware rendering working?
Thanks!

Sorry about the delay, but I have been working on it and am continuing to work on it. It just won't make it for the 3.2.1 release, which we want to release in a couple of weeks. I have some simpler examples working. I will release a version with the fix as soon as I have it fixed.

I found the problem with the black screen. In the "bin/internallauncher" script, we do a setenv QT_XCB_NATIVE_PAINTING 1 to fix a problem with the initial zoom messing up the toolbar. Removing this line caused the black screen to disappear and it now renders images. I confirmed this with all the Qt sample rendering programs in tools/examples/avtexamples as well.

Great! Will there be a hardware rendering version with 3.2.1 built that I can test this with?

Yes, I’m building a version right now. With any luck it will be ready at the end of the day.

The 3.2.1 release is now available and the RHEL7 (Red Hat Enterprise Linux 7) version supports hardware rendering and doesn't display a black screen.

Thank you very much!....I will test it tomorrow morning...

OK. Quick test on my laptop...rhel7 no longer runs on Fedora 34 giving some glibc conflict errors. I downloaded the Fedora 31
version (I am on Fedora 34) and commented the QT_XCB_NATIVE_PAINTING from the internallauncher. It starts fine but I
don't know whether this has hardware rendering or not.

Hi, rhel7 runs on desktop Fedora 34 that is using Nvidia propriety drivers with no problem. I need to check the laptop again to see what the problem was but that is using intel graphics/mesa for gl which seems to have a problem.
By the way, rhel7 versions on later Fedora versions have the problem of not finding libicu so version 50 since the installed oned
are 65 and 67. I keep a compiled versions of so 50 and copy them to the visit lib directory to make it work. Thanks!

Thanks for the feedback.
I’ll see about packaging up the libicu into the distribution for future versions. Is it just one library or are there more than one? I seem to recall that the there were 3 libraries that went together.
I’ll be interested to hear what you learn about laptop with intel graphics/mesa. I built the rhel7 version on a system with an Nvidia graphics card.

The fedora 31 version does not support hardware rendering.

These are the messages on the Lenovo Carbon X (gen 7) laptop running Fedora 34 with Intel graphics:
Running: gui3.2.1
libGL error: MESA-LOADER: failed to open iris: /usr/local/visit/3.2.1/linux-x86_64/lib/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/iris_dri.so) (search paths /usr/lib64/dri) libGL error: failed to load driver: iris libGL error: MESA-LOADER: failed to open iris: /usr/local/visit/3.2.1/linux-x86_64/lib/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/iris_dri.so) (search paths /usr/lib64/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /usr/local/visit/3.2.1/linux-x86_64/lib/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/swrast_dri.so) (search paths /usr/lib64/dri) libGL error: failed to load driver: swrast Running: viewer3.2.1 -geometry 1560x1032+360+0 -borders 26,4,4,4 -shift 0,0 -preshift 4,26 -defer -host 127.0.0.1 -port 5600 Running: mdserver3.2.1 -host 127.0.0.1 -port 5601 libGL error: MESA-LOADER: failed to open iris: /usr/local/visit/3.2.1/linux-x86_64/lib/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/iris_dri.so) (search paths /usr/lib64/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open iris: /usr/local/visit/3.2.1/linux-x86_64/lib/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/iris_dri.so) (search paths /usr/lib64/dri) libGL error: failed to load driver: iris libGL error: MESA-LOADER: failed to open swrast: /usr/local/visit/3.2.1/linux-x86_64/lib/libstdc++.so.6: version GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/swrast_dri.so) (search paths /usr/lib64/dri)
libGL error: failed to load driver: swrast

if I do stings on libstdc++.so.6.0.26 it goes up to GLIBCXX_3.4.26!  On Fedora 34 we have libstdc++.so.6.0.29. Later today I can try to if I copy those to the lib directory it would work.
The 18n package has the following libraries but I am not sure all are needed:
libicudata.so.50 -> libicudata.so.50.1.2
libicudata.so.50.1.2
libicui18n.so.50 -> libicui18n.so.50.1.2
libicui18n.so.50.1.2
libicuio.so.50 -> libicuio.so.50.1.2
libicuio.so.50.1.2
libicule.so.50 -> libicule.so.50.1.2
libicule.so.50.1.2
libiculx.so.50 -> libiculx.so.50.1.2
libiculx.so.50.1.2
libicutest.so.50 -> libicutest.so.50.1.2
libicutest.so.50.1.2
libicutu.so.50 -> libicutu.so.50.1.2
libicutu.so.50.1.2
libicuuc.so.50 -> libicuuc.so.50.1.2
libicuuc.so.50.1.2
libnek5000_interp.so

I have replaced the libstdc++ in visit lib with version 29 and it is working on the laptop! Thanls

@sambo57u Thanks for all your feedback!!
Just to summarize so that I know what extra libraries to add to the visit lib directory.
On Fedora 34 using NVidia drivers.
visit3_2_1.linux-x86_64-rhel7.tar.gz works except that it needs the libicu*.so.50.1.2
libraries. Copying them to visit/3.2.1/linux-x86_64/lib directory fixes the problem.
On Fedora 34 laptop using Intel graphics.
visit3_2_1.linux-x86_64-fedora31.tar.gz works.
visit3_2_1.linux-x86_64-rhel7.tar.gz works except that it needs the libicu*.so.50.1.2
libraries. Copying them to visit/3.2.1/linux-x86_64/lib directory fixes the problem.
Because you built the libicu*.so.50.1.2 libraries on your system (presumably with the
system compiler) the version of libstdc++.so.6 in visit/3.2.1/linux-x86_64/lib is
too old (doesn't have GLIBCXX_3.4.29). libstdc++.so.6.0.26 goes up to GLIBCXX_3.4.26.
Replacing libstdc++.so.6.0.26 with libstdc++.so.6.0.29 in visit/3.2.1/linux-x86_64/lib
directory fixes the problem.

All correct except I am not sure about the libstdc++ dependence. I built libicu some time ago and from the error messages above I see that /usr/lib64/dri/iris_dri.so is requiring this via MESA-LOADER. This is coming from mesa-dri-drivers package on the system.

Ah, that's good to know. I wonder if I can just add the latest libstdc++.so.6 I can find and add it to the lib directory and it will work on all Linux systems.

I think it would. If you look at stings in libstdc++ it lists all version up to GLIBCXX_3.4.29.

$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_DEBUG_MESSAGE_LENGTH


text:
hierarchical directed layout: edge order dependent layouting

Altering the order of the edges results in a different layout of the graph.
On this fiddle: http://jsfiddle.net/huwp23bz/ The above Graph shows the issue, each "Run" its layout changes. The bottom one shows the "how it should be" Graph.
To me it looks like the the order of the edges matters, because the edges are not sorted internally before beeing used.

The question here is how should the edges be organized. Maybe the solution to #84 could also solve this or maybe not. I would go for #84 first because guaranteeing some order could interfere with #84. If this is still an issue after #84 is resolved then we can talk about this.

@Thomaash as the bottom Graph of http://jsfiddle.net/huwp23bz/ looks like a well built graph, the given order of the edges may be the way to go. The order beeing:
for nodes from 1 to 5
edges from x to y for x and y from 1 to 4
so basically:
[
      {from: 1, to: 3},
      {from: 1, to: 4},
      {from: 2, to: 4},
      {from: 2, to: 5},
      {from: 3, to: 5},
      {from: 4, to: 5}
]

authors: Thomaash UnicornDeluxe

repo: visjs/vis-network


text:
Where ControlNet-XS model code  file in whole  code ?

Your work is good!
I want to learn from your work. Can you tell ControlNet-XS model position, I can't find it.
Thank you.   @_@

You can see in the inference config file what module is loaded.
For control of SDXL it is
network_config:
      target: sgm.modules.diffusionmodules.twoStreamControl.TwoStreamControlNet

for control of SDv2.1 it is
control_stage_config:
      target: ldm.modules.diffusionmodules.twoStreamControl.TwoStreamControlNet

cheers

authors: Sipirius motion-dream

repo: vislearn/ControlNet-XS


text:
🛑 Vistaar Digital is down

In 390f045, Vistaar Digital (https://www.vistaardigital.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Vistaar Digital is back up in 3ba836f.

repo: vistaardigital/uptime


text:
Safari date time picker styling is out

When clicking on the editable date and clicking down to change the month the Done button is in the wrong position

This is working correctly with the latest version of angular-xeditable and angular-ui-bootstrap.
@eugef please close

authors: cccastle ckosloski

repo: vitalets/angular-xeditable


text:
vite seems not support useDefineForClassFields of tpyescript

Describe the bug
useDefineForClassFields is set to true,but error ocurred when use declare modifier
Reproduction
none
Steps to reproduce
class TreeContentMenuCommon {
tree: CustomTree;
constructor(tree: CustomTree) {
this.tree = tree;
}
class TreeContentMenuSessionGroup extends TreeContentMenuCommon {
declare tree: CustomSessionTree;
constructor(tree: CustomSessionTree) {
super(tree);
}
}
System Info
[plugin:vite:vue-jsx] unknown file: The 'declare' modifier is only allowed when the 'allowDeclareFields' option of @babel/plugin-transform-typescript or @babel/preset-typescript is enabled.
78 |
79 | class TreeContentMenuSessionGroup extends TreeContentMenuGroup {

80 | declare tree: CustomSessionTree;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
81 |
82 | constructor(tree: CustomSessionTree) {
83 | super(tree);

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

my ts config
{   "compilerOptions": {     "baseUrl": "./",     "paths": {       "@/*": [         "src/*"       ]     },     "allowJs": true,     "target": "ES2022",     "useDefineForClassFields": true,     "module": "ESNext",     "lib": [       "ES2022",       "DOM",       "DOM.Iterable"     ],     "skipLibCheck": true,     /* Bundler mode */     "moduleResolution": "bundler",     "allowImportingTsExtensions": true,     "resolveJsonModule": true,     "isolatedModules": true,     "noEmit": true,     "jsx": "preserve",     /* Linting */     "strict": true,     "noUnusedLocals": true,     "noUnusedParameters": true,     "noFallthroughCasesInSwitch": true,     "types": [       "node"     ],     "typeRoots": [       "./src/types"     ],     "esModuleInterop": true,     "experimentalDecorators": true   },   "include": [     "src/**/*.ts",     "src/**/*.d.ts",     "src/**/*.tsx",     "src/**/*.vue"   ],   "references": [     {       "path": "./tsconfig.node.json"     }   ] }

repo: vitejs/vite


text:
Isomorphic libraries use wrong entry point when building SSR bundle

Describe the bug
When building a project that uses an isomorphic library such as cross-fetch, the SSR bundle uses the same entry point as the client bundle.
See related comment: https://github.com/supabase/supabase-js/issues/154#issuecomment-821966835
Reproduction
Clone repo: https://github.com/stupidawesome/vite-ssr-isomorphic-bug
yarn
yarn build
yarn start

Expected: No error
Result: XMLHTTPRequest is not defined
I've included a patched version of dep-66eb515d.js in the repo here:
Copy and paste the contents into node_modules/vite/dist/node/chunks/dep-66eb515d.js and re-run the commands above to see the difference.
System Info
Output of npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers:
  System:
    OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
    CPU: (4) arm64 unknown
    Memory: 5.82 GB / 7.56 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 14.16.1 - /usr/bin/node
    Yarn: 1.22.5 - /usr/bin/yarn
    npm: 6.14.12 - /usr/bin/npm
  npmPackages:
    vite: ^2.1.0 => 2.1.5

Used package manager: yarn

Hi @stupidawesome, I push some code to fix this issue, but I found the ssr flag alway is undefined at run svelte-kit build.
It look like is a bug for svelte, can you open an issue at svelet repo for this?

Seems like svelte already passes in build.ssr: true (link) in the build step, can you elaborate further?

authors: stupidawesome underfin


text:
Dependencies are not resolved correctly when start vite server in child packages in monorepo

Describe the bug
The source file request is broke when debugging.
Can it be scanned recursively when it is not found in the current node_modules directory？
Reproduction

using chrome devtools Sources CallStack to debug function'
click jump to the next function call. It will jump to node_modules/.vite/xxx (whose source file is provide by ../../node_modules/xxx ).
Vite server didn't correctly resolve dependcies which cause request file content return 404 and can not continue debug.

System Info
vite: 2.4.2

Used Package Manager
yarn
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

+1 on this issue
Running into a similar situation using PNPM workspaces + Vite (latest) + aws-amplify-ui libraries.
It's a big pain :-\

Hi I'd like to take a look at the issue, but I can't seem to get the behaviour as described in the reproduction step. If someone can provide a simple pnpm reproduction repro, and some specific keys to look for. That would be helpful to track down the issue.

authors: armenr bluwy lastnigtic


text:
Transitive dependency results in Vite build error while direct dependency does not

Describe the bug
When adding a dependency @cognite/3d-web-parser in package.json and importing something from it, everything runs fine.
However, when adding a dependency @cognite/3d-viewer which itself depends on @cognite/3d-web-parser and including something from @cognite/3d-viewer, Vite spits out a build error that it can not resolve the dependency @cognite/3d-web-parser with the below error message:
[plugin vite:dep-scan] Failed to resolve entry for package "@cognite/3d-web-parser". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "@cognite/3d-web-parser". The package may have incorrect main/module/exports specified in its package.json.
When looking at the @cognite/3d-web-parser#package.json#module entry, it does point to an existing index.es.js file that does seem to be in ESM format.
It might have something to do w/ yarn installing @cognite/3d-web-parser under node_modules/@cognite/3d-viewer/node_modules/3d-web-parser instead of installing it under @cognite/3d-web-parser.
I'm not sure why Yarn doesn't do that, though I'd also think that that shouldn't pose a problem to Vite.
Reproduction
https://github.com/Robin-Hoodie/vite-resolve-failure-repro
System Info
System:
    OS: macOS 12.3.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 4.00 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
    Yarn: 1.22.18 - ~/.nvm/versions/node/v16.13.1/bin/yarn
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
  Browsers:
    Brave Browser: 101.1.38.115
    Chrome: 101.0.4951.54
    Safari: 15.4
  npmPackages:
    @vitejs/plugin-react: ^1.3.0 => 1.3.2
    vite: ^2.9.9 => 2.9.9

Used Package Manager
yarn
Logs
vite:config bundled config file loaded in 47.63ms +0ms
  vite:config using resolved config: {
  vite:config   plugins: [
  vite:config     'vite:pre-alias',
  vite:config     'alias',
  vite:config     'vite:react-babel',
  vite:config     'vite:react-refresh',
  vite:config     'vite:react-jsx',
  vite:config     'vite:modulepreload-polyfill',
  vite:config     'vite:resolve',
  vite:config     'vite:optimized-deps',
  vite:config     'vite:html-inline-proxy',
  vite:config     'vite:css',
  vite:config     'vite:esbuild',
  vite:config     'vite:json',
  vite:config     'vite:wasm',
  vite:config     'vite:worker',
  vite:config     'vite:asset',
  vite:config     'vite:define',
  vite:config     'vite:css-post',
  vite:config     'vite:worker-import-meta-url',
  vite:config     'vite:client-inject',
  vite:config     'vite:import-analysis'
  vite:config   ],
  vite:config   server: {
  vite:config     preTransformRequests: true,
  vite:config     https: true,
  vite:config     fs: { strict: true, allow: [Array], deny: [Array] }
  vite:config   },
  vite:config   resolve: { dedupe: [ 'react', 'react-dom' ], alias: [ [Object], [Object] ] },
  vite:config   optimizeDeps: {
  vite:config     include: [ 'react/jsx-dev-runtime' ],
  vite:config     esbuildOptions: { keepNames: undefined, preserveSymlinks: undefined }
  vite:config   },
  vite:config   configFile: '/Users/robin/development/cognite/vite-resolve-failure-repro/vite.config.ts',
  vite:config   configFileDependencies: [
  vite:config     '/Users/robin/development/cognite/vite-resolve-failure-repro/vite.config.ts'
  vite:config   ],
  vite:config   inlineConfig: {
  vite:config     root: undefined,
  vite:config     base: undefined,
  vite:config     mode: undefined,
  vite:config     configFile: undefined,
  vite:config     logLevel: undefined,
  vite:config     clearScreen: undefined,
  vite:config     server: {}
  vite:config   },
  vite:config   root: '/Users/robin/development/cognite/vite-resolve-failure-repro',
  vite:config   base: '/',
  vite:config   publicDir: '/Users/robin/development/cognite/vite-resolve-failure-repro/public',
  vite:config   cacheDir: '/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/.vite',
  vite:config   command: 'serve',
  vite:config   mode: 'development',
  vite:config   isWorker: false,
  vite:config   isProduction: false,
  vite:config   build: {
  vite:config     target: [ 'es2019', 'edge88', 'firefox78', 'chrome87', 'safari13.1' ],
  vite:config     polyfillModulePreload: true,
  vite:config     outDir: 'dist',
  vite:config     assetsDir: 'assets',
  vite:config     assetsInlineLimit: 4096,
  vite:config     cssCodeSplit: true,
  vite:config     cssTarget: [ 'es2019', 'edge88', 'firefox78', 'chrome87', 'safari13.1' ],
  vite:config     sourcemap: false,
  vite:config     rollupOptions: {},
  vite:config     minify: 'esbuild',
  vite:config     terserOptions: {},
  vite:config     write: true,
  vite:config     emptyOutDir: null,
  vite:config     manifest: false,
  vite:config     lib: false,
  vite:config     ssr: false,
  vite:config     ssrManifest: false,
  vite:config     reportCompressedSize: true,
  vite:config     chunkSizeWarningLimit: 500,
  vite:config     watch: null,
  vite:config     commonjsOptions: { include: [Array], extensions: [Array] },
  vite:config     dynamicImportVarsOptions: { warnOnError: true, exclude: [Array] }
  vite:config   },
  vite:config   preview: {
  vite:config     port: undefined,
  vite:config     strictPort: undefined,
  vite:config     host: undefined,
  vite:config     https: true,
  vite:config     open: undefined,
  vite:config     proxy: undefined,
  vite:config     cors: undefined,
  vite:config     headers: undefined
  vite:config   },
  vite:config   env: { BASE_URL: '/', MODE: 'development', DEV: true, PROD: false },
  vite:config   assetsInclude: [Function: assetsInclude],
  vite:config   logger: {
  vite:config     hasWarned: false,
  vite:config     info: [Function: info],
  vite:config     warn: [Function: warn],
  vite:config     warnOnce: [Function: warnOnce],
  vite:config     error: [Function: error],
  vite:config     clearScreen: [Function: clearScreen],
  vite:config     hasErrorLogged: [Function: hasErrorLogged]
  vite:config   },
  vite:config   packageCache: Map(0) {},
  vite:config   createResolver: [Function: createResolver],
  vite:config   worker: {
  vite:config     format: 'iife',
  vite:config     plugins: [
  vite:config       [Object], [Object],
  vite:config       [Object], [Object],
  vite:config       [Object], [Object],
  vite:config       [Object], [Object],
  vite:config       [Object], [Object],
  vite:config       [Object], [Object],
  vite:config       [Object], [Object],
  vite:config       [Object], [Object],
  vite:config       [Object]
  vite:config     ],
  vite:config     rollupOptions: {}
  vite:config   }
  vite:config } +3ms

  vite v2.9.9 dev server running at:

  > Local: https://localhost:3000/
  > Network: use `--host` to expose

  ready in 115ms.

  vite:deps scanning for dependencies... { timestamp: true } +0ms
  vite:deps Crawling dependencies using entries:
  vite:deps   /Users/robin/development/cognite/vite-resolve-failure-repro/index.html +0ms
  vite:resolve 0.26ms /src/main.tsx -> /Users/robin/development/cognite/vite-resolve-failure-repro/src/main.tsx +0ms
  vite:resolve 1.15ms react -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/react/index.js +1ms
  vite:resolve 0.50ms react-dom/client -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/react-dom/client.js +1ms
  vite:resolve 0.30ms ./App -> /Users/robin/development/cognite/vite-resolve-failure-repro/src/App.tsx +1ms
  vite:resolve 0.42ms @cognite/3d-viewer -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@cognite/3d-viewer/dist/cognite.module.js +1ms
  vite:deps Scan completed in 17.34ms: {
  react: '/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/react/index.js',
  'react-dom/client': '/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/react-dom/client.js',
  '@cognite/3d-viewer': '/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@cognite/3d-viewer/dist/cognite.module.js'
} +9ms
  vite:resolve 0.31ms react/jsx-dev-runtime -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/react/jsx-dev-runtime.js +0ms
  vite:deps dependencies found: @cognite/3d-viewer
  vite:deps   react
  vite:deps   react-dom/client
  vite:deps   react/jsx-dev-runtime { timestamp: true } +25ms
  vite:resolve 0.30ms react-dom -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/react-dom/index.js +0ms
  vite:resolve 0.29ms react -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/react/index.js +3ms
  vite:resolve 1.44ms @babel/runtime/regenerator -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/regenerator/index.js +9ms
  vite:resolve 1.58ms @babel/runtime/helpers/asyncToGenerator -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/helpers/asyncToGenerator.js +2ms
  vite:resolve 1.20ms @babel/runtime/helpers/classCallCheck -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/helpers/classCallCheck.js +1ms
  vite:resolve 1.41ms @babel/runtime/helpers/createClass -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/helpers/createClass.js +2ms
  vite:resolve 0.57ms @tweenjs/tween.js -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@tweenjs/tween.js/src/Tween.js +1ms
  vite:resolve 0.37ms three -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@cognite/3d-viewer/node_modules/three/build/three.module.js +0ms
  vite:resolve 1.21ms @babel/runtime/helpers/toConsumableArray -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/helpers/toConsumableArray.js +2ms
  vite:resolve 0.24ms right-now -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/right-now/browser.js +0ms
✘ [ERROR] [plugin vite:dep-pre-bundle] Failed to resolve entry for package "@cognite/3d-web-parser". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "@cognite/3d-web-parser". The package may have incorrect main/module/exports specified in its package.json.

    node_modules/vite/dist/node/chunks/dep-59dc6e00.js:40662:10:
      40662 │     throw new Error(`Failed to resolve entry for package "${id}". ` +
            ╵           ^

    at packageEntryFailure (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:40662:11)
    at resolvePackageEntry (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:40658:9)
    at tryNodeResolve (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:40465:20)
    at Context.resolveId (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:40273:28)
    at Object.resolveId (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:38837:55)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:61503:27
    at async /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:38354:34
    at async callback (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:921:28)
    at async handleRequest (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:701:30)

  This error came from the "onResolve" callback registered here:

    node_modules/vite/dist/node/chunks/dep-59dc6e00.js:38333:18:
      38333 │             build.onResolve({ filter: /^[\w@][^:]/ }, async ({ path: id, importer, kind }) => {
            ╵                   ~~~~~~~~~

    at setup (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:38333:19)
    at handlePlugins (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:843:23)
    at Object.buildOrServe (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:1137:7)
    at /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:2079:17
    at new Promise (<anonymous>)
    at Object.build (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:2078:14)
    at Object.build (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:1927:51)
    at runOptimizeDeps (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:39574:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

  The plugin "vite:dep-pre-bundle" was triggered by this import

    node_modules/@cognite/3d-viewer/dist/cognite.module.js:1:4088:
      1 │ ...rray")},function(e,t){e.exports=require("right-now")},function(e,t){e.exports=require("@cognite/3d-web-parser")},function(e,t,n){"use strict";var r=this&&this.__assign||function(){return(r=Object....
        ╵                                                                                ~~~~~~~~~~~~~~~~~~~~~~~~

  vite:resolve 0.69ms is-function -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/is-function/index.js +26ms
  vite:resolve 0.40ms scheduler -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/scheduler/index.js +1ms
  vite:resolve 0.40ms mouse-event-offset -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/mouse-event-offset/index.js +0ms
  vite:resolve 1.17ms @babel/runtime/helpers/defineProperty -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/helpers/defineProperty.js +1ms
  vite:resolve 0.25ms @cognite/three-combo-controls -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@cognite/3d-viewer/node_modules/@cognite/three-combo-controls/dist/main.js +1ms
  vite:resolve 0.95ms @babel/runtime/helpers/slicedToArray -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/helpers/slicedToArray.js +1ms
  vite:resolve 0.88ms @babel/runtime/helpers/typeof -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/@babel/runtime/helpers/typeof.js +1ms
  vite:resolve 0.22ms mixpanel-browser -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/mixpanel-browser/dist/mixpanel.cjs.js +0ms
  vite:resolve 0.27ms simple-statistics -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/simple-statistics/dist/simple-statistics.js +0ms
  vite:resolve 0.28ms regenerator-runtime -> /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/regenerator-runtime/runtime.js +1ms
12:24:42 PM [vite] error while updating dependencies:
Error: Build failed with 1 error:
node_modules/vite/dist/node/chunks/dep-59dc6e00.js:40662:10: ERROR: [plugin: vite:dep-pre-bundle] Failed to resolve entry for package "@cognite/3d-web-parser". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "@cognite/3d-web-parser". The package may have incorrect main/module/exports specified in its package.json.
    at failureErrorWithLog (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:1603:15)
    at /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:1249:28
    at runOnEndCallbacks (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:1034:63)
    at buildResponseToResult (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:1247:7)
    at /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:1356:14
    at /Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:666:9
    at handleIncomingPacket (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:763:9)
    at Socket.readFromStdout (/Users/robin/development/cognite/vite-resolve-failure-repro/node_modules/esbuild/lib/main.js:632:7)
    at Socket.emit (node:events:390:28)
    at addChunk (node:internal/streams/readable:315:12)

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

The direct reason is @cognite/3d-web-parser's browser field points to a non-existant file (dist/main.js).
The behavior difference between direct and transitive dep comes from the difference of Vite's resolver and esbuild's resolver. esbuild's one fallbacks to another entry point if the browser field points to a file which does not exist. Vite's one does not do that.

@sapphi-red Thanks for the answer. If I understood you correctly, ESBuild resolves transitive dependencies, while Vite resolves direct dependencies. If that's the case, doesn't that mean that you meant it the other way around and that Vite does fallback and ESBuild does not?
Also, is there a reason why both prefer the browser field over the module field if both tools prefer ES Modules?

ESBuild resolves transitive dependencies, while Vite resolves direct dependencies.

Partially yes.
Vite uses esbuild with Vite's resolver plugin. So... I am a bit lying here.
I forgot the details but I remember I confirmed that Vite does not fallback and esbuild (without Vite's resolver plugin) does fallback.

is there a reason why both prefer the browser field over the module field if both tools prefer ES Modules?

I think this is the reason.
https://twitter.com/youyuxi/status/1348413401299562497

Thanks for the context.
Reading Evan's comment, I wasn't even aware there was a difference between NodeJS ESM & browser ESM. Isn't the whole point of ESM to have a module format that works for both?

The formats are same. browser ESM stands for ESM with browser specific code (like window.alert).

The formats are same. browser ESM stands for ESM with browser specific code (like window.alert).

That makes sense. Thanks for all the help!
Closing this as the issue lies in @cognite/3d-web-parser and its package.json#browser entry

authors: Robin-Hoodie sapphi-red


text:
feat(env): support dotenv-expand to contains process env

Description
close: #6626

Additional context

What is the purpose of this pull request?

[ ] Bug fix
[x] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

Marking this as a breaking change and for 4.0 since there were regression reports when we last tried to update, but thanks for starting work on this! We could be merging this once 4.0 is near.

Hope version 4 will come soon😁

Vite 4 will follow shortly after Rollup 3 is released, which is soon I think 👍

I think bumping dotenv-expand can be done independently without this change because we're not using the change in 9.0.0.
Also dotenv-expand requires dotenv v16. (It doesn't include peerDep though.) So I think we should upgrade it together if we are upgrading dotenv-expand.
https://github.com/motdotla/dotenv-expand/blob/master/CHANGELOG.md#800-2022-02-03

I think bumping dotenv-expand can be done independently without this change because we're not using the change in 9.0.0.

Yes

Also dotenv-expand requires dotenv v16. (It doesn't include peerDep though.) So I think we should upgrade it together if we are upgrading dotenv-expand. https://github.com/motdotla/dotenv-expand/blob/master/CHANGELOG.md#800-2022-02-03

I can make a new PR to support #10149, or do it here and close #10149, what do you think?

I can make a new PR to support #10149, or do it here and close #10149, what do you think?

IMHO it would be better to remove bumping dotenv-expand from this PR and splitted into a PR that includes upgrading dotenv.

Thanks for updating!

I just noticed that it throws an error with dotenv-expand@>=6.0.0 if a user had an env var that includes $.
The error is TypeError: Cannot read properties of undefined (reading 'split') that is same with https://github.com/vitejs/vite/issues/6858.
With powershell, you can reproduce by running $env:VITE_FOO="$`f"; pnpm dev. With bash, I guess $VITE_FOO="\$f" pnpm dev will do the same thing.
This is not a direct blocker of this PR, but this PR will block #10826 if merged.
Maybe we should wait for dotenv-expand to fix that. Or we could make a PR to dotenv-expand and apply that patch with pnpm patch for a while (It works because we are bundling dotenv-expand).

This is not a direct blocker of this PR, but this PR will block #10826 if merged.
Maybe we should wait for dotenv-expand to fix that. Or we could make a PR to dotenv-expand and apply that patch with pnpm patch for a while (It works because we are bundling dotenv-expand).

Ok, I see, I think we can fix the problem with dotenv-expand in #10826, instead of blocking this PR.

authors: Dunqing bluwy sapphi-red


text:
docs(backend-integration): update import for modulepreload polyfill

Description
The issue is described here - https://github.com/vitejs/vite/issues/4786
What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[x] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

From https://github.com/vitejs/vite/issues/4786#issuecomment-984340904, this approach is problematic in TS, no?

@ygj6 no, TS/ts-lint just complaining about imports/etc. The issue is also reproducible on react w/o TS.
Here is the reproduction of this: https://codesandbox.io/s/5hgsj?file=/src/main.jsx
Polyfill was imported in main.jsx in order not to simulate backend. To see the error you just need to open sandbox's little browser window in new tab and open console. If the html would be rendered via backend, there would be nothing on the screen

no, TS/ts-lint just complaining about imports/etc.

@katsu223 Apologise for my misleading review, I was talking about complaints from TS/ts-lint. It does fix the problem, but it also prompts the type error in TS. Not sure if this is a good solution.

@ygj6, thanks for clarifications. I am not good at typescript, but I will try to dive into the problem and find the solution


text:
workflow: separate version bumping and publishing on release

Workflow Changes

npm run release script moved to top-level with an interactive prompt to select the package
version bumping is done with npm run release instead of GH action dispatching
The flow of releasing becomes:

Maintainer runs npm run release locally at project root of the latest main branch
Select the package and version that need to be released
The scripts handle version bumping, changelog, git commit with tag and push it to GH
The commit tag triggers Actions to do the building and publishing on CI https://github.com/vitejs/vite/actions/workflows/publish.yml
Done.

Changes Details

npm run release moved to root, and no longer runs building and publishing.
--skipBuild option has been removed. We use prepublishOnly hook to trigger the build before publishing.
changelog scripts in each package has been inlined in the release script to reduce duplication
Use npm publish instead of yarn publish since we already handle the version bumping.

The flow looks awesome Anthony, after seeing the three clicks (because of the environment approval) and waiting at each step for the GitHub UI to respond when using dispatch, it makes a lot more sense to use the CLI as you proposed.

https://user-images.githubusercontent.com/11247099/153708071-4548745b-6d1f-4f67-b03a-06f2812da9b7.mp4
Added a little helper to show the git diff since last release

authors: antfu patak-dev


text:
mocks folder does not work

Describe the bug
We are migrating a code base from jest to vitest. I am struggling to get the __mocks__ folder to work as described in the docs.
If this is an implementation error, and it does in fact work as expected, I would suggest using more clear examples of how this functionality is intended to work in the documentation.
Reproduction
I created a mock for the uuid module which should always return generated-id. This mock is not picked up.
https://stackblitz.com/edit/vitest-dev-vitest-aqqg5j?file=__mocks__/uuid.ts
System Info
System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 7.17.0 - /usr/local/bin/npm
  npmPackages:
    @vitest/ui: latest => 0.30.1
    vite: latest => 4.2.1
    vitest: latest => 0.30.1

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

After looking at this again it seems that it was an error with my implementation. I've updated the Stackblitz link with the working example.

repo: vitest-dev/vitest