text:
Refactor register.c to remove calls to STRLEN()

Added new struct string_T to store a string with it's length.
Also, fix a bug in charwise_block_prep() in ops.c where bdp->textlen is off-by-one if the selection runs over the end of the line. Adjust test_visual.vim accordingly.

Adjust test_visual.vim accordingly.

Why? Shouldn't f_getregionpos() be fixed instead?

f_getregionpos() calls charwise_block_prep() (in ops.c) to retrieve starting positions and offsets which is then reported. This function has the off-by-one error (eg string 'one' was being reported at having a ->textlen of 4, instead of 3 if it occurs at the end of a line). test_visual.vim was checking for the higher number.
Have I taken the wrong approach here?

This makes the ending column of charwise selection inconsistent with linewise selection. With eol: v:false, the ending column is one more than the line length for every line in a linewise selection and every non-last line in the charwise selection, but with PR it is no longer than case for charwise selection.
Also, with eol: v:false,

if a line is empty or the selection is entirely beyond the end of a line, a "col" value of 0 is used for both positions.

This can happen for charwise selection with 'virtualedit', as can be seen in this test case:
    call cursor(1, 3)
    call feedkeys("\<ESC>lvjj3l", 'tx')
    call assert_equal(['', 'two', 'three  '],
          \ getregion(getpos('v'), getpos('.'), {'type': 'v' }))
    call assert_equal([
          \   [[bufnr('%'), 1, 0, 0], [bufnr('%'), 1, 0, 0]],
          \   [[bufnr('%'), 2, 1, 0], [bufnr('%'), 2, 3, 0]],
          \   [[bufnr('%'), 3, 1, 0], [bufnr('%'), 3, 5, 0]],
          \ ],
          \ getregionpos(getpos('v'), getpos('.'), {'type': 'v' }))

With this PR the ending column changes to the length of the line, which is inconsistent with a blockwise selection entirely beyond the end of the line, for which the ending column is still 0.

Thanks. Can you back out the change to getregion()? So we have a single PR for one single fix/enhancement?

I will back out the change to ops.c and the test. Stay tuned...

can you please re-run? I have seen this sometimes, but not sure why the xml indent test fails

thanks!

authors: basilisk0315 chrisbra zeertzjq


text:
Added Strict Mode when in debug

Closes #11

Nice, thanks for your PR !

source: gharchive/pull-request

authors: rafaeltoledo vincentbrison

repo: vincentbrison/vb-android-app-quality

license_type: permissive

license_source: bigquery


text:
Feature request?

Hi Folks, I opened this rather than PR at this stage to gauge interest. I forked this excellent tile due to a need at work to create a dashboard for our uptime monitoring, with about 50+ urls/ips monitored.  I have edited the tile.blade.php to include a little apline.js to handle monitors being grouped by status. Dynamic filter applied to display downed monitors at the top of the list.
If there is any of this you like then please let know what you'd be interested in by way of a PR.
main differences  / additions:
    public function monitorsByStatus(): array
    {
        $monitors = collect($this->tile->getData('monitors'));
        $monitorTypes = config('dashboard.tiles.uptimerobot.monitor_types');

        if (!empty(config('dashboard.tiles.uptimerobot.monitors'))) {
            $monitors = $monitors->filter(function ($item, $key) {
                return in_array($item['id'], config('dashboard.tiles.uptimerobot.monitors'));
            });
        }

        foreach ($monitors as $monitor) {
            $monitor['badge'] = $this->badges[$monitor['status']];
            $monitor['status'] = $this->statuses[$monitor['status']];
            $monitor['monitor_type'] = $monitorTypes[$monitor['type']];
            $this->monitors[$monitor['status']][] = $monitor;
        }

        return $this->monitors;
    }

            <template x-for="monitor_states in monitors">

 0)"
                     class="grid grid-cols-7 card-scrollbar">
                    <template x-for="monitor in monitor_states"
                              x-init="console.log((monitor_states.length > 0))">

                    </template>

            </template>

Best wishes

Hi, I really like the idea with grouping the tiles by status, and I'm sure others would like it too. A PR would definitely be appreciated.

source: gharchive/issue

authors: RobertByrnes vinevax

license: MIT

license_source: github-api


text:
Fix mutation of dictionary during iteration

First of all, thank you for an awesome implementation! It helped me understand the intrinsic features of GOAP. We're planning to use some of your code in our game. Great job!
This PR fixes an issue with having a blackboard of several items and a plan with several actions.

That's great. I'm glad you found it useful. Thanks for keeping this sample updated. Cheers

repo: viniciusgerevini/godot-goap


text:
Add cmake build to travis #2

based on https://github.com/vinniefalco/Beast/pull/29

Coverage remained the same at 98.116% when pulling 6cdfe394a48899a282df0e6d1a35f0a7b1ad8397 on wilsonianb:cmake into f8a1ec03480ce255dfe7f834524749e454925f42 on vinniefalco:master.

[Current coverage][cc-pull] is 98.11%

Merging [#39][cc-pull] into [master][cc-base-branch] will increase coverage by 0.02%

@@             master        #39   diff @@
==========================================
  Files            72         71      -1
  Lines          5083       4035   -1048
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           4986       3959   -1027
+ Misses           97         76     -21
  Partials          0          0

Powered by Codecov. Last updated by [f8a1ec0...6cdfe39][cc-compare]
[cc-base-branch]: https://codecov.io/gh/vinniefalco/Beast/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/vinniefalco/Beast/compare/f8a1ec03480ce255dfe7f834524749e454925f42...6cdfe394a48899a282df0e6d1a35f0a7b1ad8397
[cc-pull]: https://codecov.io/gh/vinniefalco/Beast/pull/39?src=pr

:+1:

authors: codecov-io coveralls seelabs wilsonianb

repo: vinniefalco/Beast


text:
Add enable/disable configuration for resetting of data and add UI fix…

…es for listing and forms of import

@nimish13 Done


text:
Feed: インフラの更新情報

この Issue にボットに関する更新情報を流します。 Subscribe すると更新情報を受け取れます。

/build/lambda/conv2img コマンドを作成
https://github.com/violet-ts/violet/pull/79#issuecomment-960931325

PR ラベル付与
管理しているラベルは手動でつけても外される（とりあえず今の所）
いくつかありますが、コミットを conventional commit として解釈して feat, fix, docs, test, refactor に反応します。
fix は注意してください。同一 PR 内に関する修正であれば chore を使い、ベースブランチにあるバグを修正した場合に fix を使ってください。
また、conventional commit はタイプのあとに空白が必要です。 fix:<space> など

diff/ は差分のあった行数ごとに計算されます。 size/ とは別です。 PR 側のラベルは主にレビューや見直し用。

Bot の修正を行いました。 ただし、 https://github.com/violet-ts/violet/pull/91 のマージが必要です
デフォルトネームスペースを issue/pr を作ったユーザ名にしました。 /switch も用意しましたが、複数 PR レビュー待ちなどでなければ使う機会は少ないかもしれません
/deploy コマンドを用意しました。
上記により、新しく PR を開いたら /deploy を叩いておけばプレビューに必要なものを、前回の環境を引き継いで用意します。シーディングはしないので手動で行ってください。

コンテナビルドは 5 分程度で終わります
インフラ構築はゼロから作ると 7 分、引き継いだ状態から作ると 2 分程度で終わります

直列実行を 1 コメントで記述できるようになりました
詳しくは wiki ページを御覧ください。 wiki/Bot の使い方
Bot の更新方針を変えます。あまり動いているものを壊したくないため、Bot 開発用の環境を別で作ることにします。壊れる頻度をこれで減らそうと思います

前回の更新からバージョニング。 前回は v0.1.0。
今回は v0.2.0。 ./docker/prod/... 内の Dockerfile を見るように変更。https://github.com/violet-ts/violet/issues/95 に合わせて。

v0.3.0, v0.3.1

Lambda for conv2img のデプロイ準備完了

MEM 1GB (NOTE: Lambda は CPU は MEM に比例) で 19s、ローカルだと 6s で終わるファイル (1ページのPDF)
チューニングはもう少しする

S3 Bucket を変換前後用に用意し、変換前に対する write ができない権限と変換前しか検知しないイベント登録で無限ループは回避
DLQ を配置。変換失敗したファイルは今のところ、ここを見れば確認できる。アラームは別途、整備する予定。

v0.4.0

Google Cloud Identity Platform (GCIP) 対応
現在の main ブランチを rebase/merge したあとであれば、プレビュー環境では GitHub/Email で認証可能な状態になります
Email は今の所適当に入れたりなどをしていないのですが、必要であればプレビュー環境用のデモ Email アカウントも増やします

v0.5.0

Next.js のビルドサマリーを PR にコメントで返すように。再実行後は前のコメントが更新される。

v0.6.0

original/converted バケットのACLを public から read 可能に、CORS もとりあえず全操作どこからでも可能に

v0.7.0

Lighthouse 関連のコマンドを実装
/deploy で Lighthouse 用の seed をセットアップして Lighthouse を事前定義したパスプリセットに対して実行するように

ECS が立ち上がってない可能性はあるのでそのへんの調整は今後必要かもしれない
Actions のほうがいいかもしれない、などは考えているが、リアルに近いほうがいいかもしれない、とも思っている。SEO や best practice, accessibility は Actions にして、Performance は Preview 環境に対して、というのも考えている。

/seed が dev にしか対応していなかったが、 lighthouse に対応するついでに任意の名前に対応

v0.8.0
久しぶりなのでまず軽めのを…。

/preview/start 時にCloudWatchダッシュボードを作成するように

異常をわかりやすくしたり、大域的な傾向を視覚的に見れる。よりよさそうな指標があれば今後も追加・改良していく。
/preview/start 等のコマンド内で 「Dashboard for ...」と書かれている部分からアクセス可能。

v0.9.0

Create developer portal

DevやOpsは、管理者(SRE)なしでAWS IAMアカウントを作成したり、アクセスキーを生成・削除できるようになります。

https://portal.violet-dev.com/ よりアクセス可能。
今後は GitHub の PR 上でしか使えなかった bot を使えるようにしたりなどを考えている。

repo: violet-ts/violet-infrastructure


text:
Custom CSS

How to add custom CSS in this admin panel?

@afoysal  you can write your custom css in public/css/backend/backend-custom.css.
We have already  written few CSS there.

https://i.stack.imgur.com/rEtZv.png

@afoysal you can create your own custom CSS and include in the layout. please let me know if you have any queries or concerns.

authors: afoysal viralsolani

repo: viralsolani/laravel-adminpanel

license: mit


text:
-bash: snpguest: command not found

I installed snpguest according to the instructions in the building section of the readme and did not receive any error messages. However, when I entered the command "snpguest --help", it prompted an error saying "-bash: snpguest: command not found". Can someone please help me with this?

I fixed it by using cargo install snpguest

Hi @ccylance
It seems that you may not be specifying the exact path of the snpguest binary.
From the root of the snpguest directory:
$ cargo build -r
$ ./target/release/snpguest --help

If you want to just run snpguest --help (or any other subcommand), copy the binary to /usr/bin.
From the root of the snpguest directory:
$ cargo build -r
$ cp ./target/release/snpguest /usr/bin
$ snpguest --help

I fixed it by using cargo install snpguest

Great. If you were compiling locally, the above instructions would work for you.

authors: ccylance tylerfanelli

repo: virtee/snpguest


text:
Errenous RequestDuration measurement using ETW

I have been trying to measure per-request response time under KVM as seen from Windows using the methodology described here. The disk is passed through using virtio-scsi to the VM, but the "RequestDuration" value returned by the ETW is always 0. Exact same disk generates correct results when I boot directly from it. I am using Fedora virtio drivers.
Is this because of the fundamental design virtio-scsi driver? Or is the driver not initializing a data structure, flipping a bit, etc?
Thanks for all the efforts!

Hi all,
I tried to reproduce this issue on rhel8.3.1 host, reproduce step was similar with comment#0, I can reproduce this issue.
I tested with a qemu simulated raw file,  did not test with a virtio-scsi passthrough disk. Tried with virtio-blk(viostor) and virtio-scsi(vioscsi) driver, both reproduced this issue, the "RequestDuration" value returned by the ETW is always 0.
Qemu commands:
For virtio-scsi:
-device virtio-scsi-pci,id=scsi0,bus=root2.0, -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=192SCS126435AWK_test.raw,node-name=my_scsi -blockdev driver=raw,node-name=myscsi,file=my_scsi -device scsi-hd,bus=scsi0.0,drive=myscsi,id=scsi-disk0,serial=whql_test
For virtio-blk:
-blockdev node-name=file_image1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kvm_autotest_root/images/win8-64-virtio.qcow2,cache.direct=on,cache.no-flush=off
-blockdev node-name=drive_image1,driver=qcow2,read-only=off,cache.direct=on,cache.no-flush=off,file=file_image1
-device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3
-device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,write-cache=on,bus=pcie-root-port-2,addr=0x0 \
Used version:
kernel-4.18.0-240.11.1.el8_3.x86_64
qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64
seabios-bin-1.14.0-1.module+el8.3.0+7638+07cf13d2.noarch
virtio-win-prewhql-192
Best Regards~
Peixiu

Hi all,
I tried to reproduce this issue on rhel8.3.1 host, reproduce step was similar with comment#0, I can reproduce this issue.
I tested with a qemu simulated raw file,  did not test with a virtio-scsi passthrough disk. Tried with virtio-blk(viostor) and virtio-scsi(vioscsi) driver, both reproduced this issue, the "RequestDuration" value returned by the ETW is always 0.
Qemu commands:
For virtio-scsi:
-device virtio-scsi-pci,id=scsi0,bus=root2.0, -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=192SCS126435AWK_test.raw,node-name=my_scsi -blockdev driver=raw,node-name=myscsi,file=my_scsi -device scsi-hd,bus=scsi0.0,drive=myscsi,id=scsi-disk0,serial=whql_test
For virtio-blk:
-blockdev node-name=file_image1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kvm_autotest_root/images/win8-64-virtio.qcow2,cache.direct=on,cache.no-flush=off
-blockdev node-name=drive_image1,driver=qcow2,read-only=off,cache.direct=on,cache.no-flush=off,file=file_image1
-device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3
-device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,write-cache=on,bus=pcie-root-port-2,addr=0x0 \
Used version:
kernel-4.18.0-240.11.1.el8_3.x86_64
qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64
seabios-bin-1.14.0-1.module+el8.3.0+7638+07cf13d2.noarch
virtio-win-prewhql-192
Best Regards~
Peixiu

I do have some patch set to deal with IoTargetRequestServiceTime notification
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/nf-storport-storportnotification
Honestly, I didn't find it very useful for tracing performance issues, mostly because the same results can be obtained
by checking the difference between two time stamps - when a particular SRB was completed and when it was issued.
However, I can submit my patches if you think that it still can be useful.
Cheers,
Vadim

I do have some patch set to deal with IoTargetRequestServiceTime notification
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/nf-storport-storportnotification
Honestly, I didn't find it very useful for tracing performance issues, mostly because the same results can be obtained
by checking the difference between two time stamps - when a particular SRB was completed and when it was issued.
However, I can submit my patches if you think that it still can be useful.
Cheers,
Vadim

I do have some patch set to deal with IoTargetRequestServiceTime notification
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/nf-storport-storportnotification
Honestly, I didn't find it very useful for tracing performance issues, mostly because the same results can be obtained
by checking the difference between two time stamps - when a particular SRB was completed and when it was issued.
However, I can submit my patches if you think that it still can be useful.

Thanks for your explanation, I got it, and I agree to close this issue.
Best Regards~
Peixiu

I do have some patch set to deal with IoTargetRequestServiceTime notification
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/nf-storport-storportnotification
Honestly, I didn't find it very useful for tracing performance issues, mostly because the same results can be obtained
by checking the difference between two time stamps - when a particular SRB was completed and when it was issued.
However, I can submit my patches if you think that it still can be useful.

Thanks for your explanation, I got it, and I agree to close this issue.
Best Regards~
Peixiu

authors: peixiu tarihi vrozenfe

repo: virtio-win/kvm-guest-drivers-windows


text:
Client Owned Objects Not Destroyed On Disconnect

Mirror master
player prefab with script below attached, and another prefab with Network Identity
assign both prefabs to Network Manager as per usual
build and run client
play server in editor
connect and disconnect client

Bug: the object spawned with client authority is left behind
Expected: client-owned objects should be destroyed when client disconnects
using Mirror;
using UnityEngine;

public class SpawnPet : NetworkBehaviour
{
    [SerializeField]
    private GameObject _petPrefab;

    public override void OnStartClient()
    {
        base.OnStartClient();
        //If has authority then spawn pet.
        if (base.hasAuthority)
            CmdSpawnPet();
    }

    [Command]
    private void CmdSpawnPet()
    {
        GameObject petInstance = Instantiate(_petPrefab);
        NetworkServer.Spawn(petInstance, base.connectionToClient);
    }
}

:tada: This issue has been resolved in version 6.5.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


text:
connectionToClient returning null if not called for host

Describe the bug
connectionToClient is null unless it's a host. I tried over my localhost 2 clients, and the host client runs without problem, and the client client gives the object not set to an instance of an object error
[IMPORTANT] How can we reproduce the issue, step by step:
Here's my method that has that problem:
    public void ReplacePlayer(int i) {
        NetworkConnection conn;

        conn = GetComponentInParent<NetworkIdentity>().connectionToClient;
        Debug.Log(conn);

        GameObject oldPlayer = conn.identity.gameObject;

        NetworkServer.ReplacePlayerForConnection(conn, Instantiate(Prefabs[i]), true);

        NetworkServer.Destroy(oldPlayer);
    }

It's pretty much just the code from the "Custom Character Spawning" guide, with only added getting the connection.
Expected behavior
Player prefab changes to the chosen prefab in the dropdown in UI
Desktop (please complete the following information):

OS: Windows 10 Pro
Build target: Windows
Unity version: 2021.2.7f1
Mirror branch: mirror from the asset store

Pretty sure this is not a bug. Connection to client is just the how the server knows what connection owns what object.
Via the docs: "This is only valid for client-owned objects (including the Player object) on the server"
Even if that did somehow work, that method would still fail as it uses NetworkServer functions, which is only valid for the server, if you couldn't guess.

ReplacePlayer has to be run server side.  For support please join our Discord.

Pretty sure this is not a bug. Connection to client is just the how the server knows what connection owns what object. Via the docs: "This is only valid for client-owned objects (including the Player object) on the server"
Even if that did somehow work, that method would still fail as it uses NetworkServer functions, which is only valid for the server, if you couldn't guess.
One potential way to do what I'm assuming you want to do is to make ReplacePlayer a [Command], so it will always run on the server.

ReplacePlayer has to be run server side. For support please join our Discord.

it is a player gameobject, and I did try turning it into [Command], which just kicks the player out, with the error on the host that says it kicked him for a null reference error, the same error that happens if it's not a [command]

authors: JohnCorby MrGadget1024 siladrenja


text:
Telegram.ChatBot behaviour doesn't currently handle inline mode

Howdy,
I'm working on a bot where I'd like to take advantage of the semi-persistent state provided by Telegram.ChatBot but also support inline mode. Currently when I enable inline mode for the bot it just discards all of the updates that telegram sends because there's no chat id associated with them. I'm happy to take a stab at adding support for this, but wanted to run the concept by you before writing code.
Currently Telegram.Bot.ChatBot.Chat.Session.Server emits the following logs when an inline mode query is typed in some chat:
[debug] process_update: %{"inline_query" => %{"chat_type" => "private", "from" => <user-object that's sending the request>, "id" => "<query-identifier>", "offset" => "<offset for results to send>", "query" => "<query-text>"}, "update_id" => <update-id>}
[info] Dropped update without chat <same object as above>

There's some more info here: https://core.telegram.org/bots/api#inline-mode
At a high level, I feel like it could be reasonable to treat the inline query similar to a chat - i.e. spin up a new instance of the bot, call init, handle_update, etc. like it already does; and just treat the inline query identifier as the chat id instead of trying to find a chat.
Once again, I'm happy to throw up a PR with some changes to support this just wanted to get on the same page as you first :)

Hey @lnr0626, got the point.
Yes, I think your analysis is correct and points in the right direction.
I'm thinking about the inline query interaction. Let me explain, but bear with me if I'm a bit rusty on some telegram features.
If my memories are right inline queries are just a simple "one-off" requests-response interaction with a BOT, so they do not establish a real chat but just ask for something and get an answer. This is my feeling given there isn't a chat it in the protocol, but just an inline query id to reply back from the BOT.
If this is right then this one-off interaction with a statefull bot could be modeled as a transient chat that lives just that interaction. It means, as you said, spawning a new chat session to answer the inline query and then release the session immediately.
May I ask you to dig a bit into it to validate that?
One interesting test could be to send an inline query to a NON-statefull BOT (it should answer) then send another inline query from the same private chat and checks the id of the two requests.
They should have different ids.

That's correct - each inline query gets it's own id, for example:
@bot_name t
@bot_name th
@bot_name the

results in 3 different ids. This is also true when the bot paginates it's responses (i.e. it answers with a non-empty next offset and telegram handles iterating through the pages to display all results, each of the follow-on requests will have a different query id)
Given that, modelling it as a transient chat makes sense to me

repo: visciang/telegram


text:
Async view support

This is a somewhat controversial topic for views. Here are my opinions.
The good:

we could pass "promise"-like objects to the view and forget about them (db queries etc)
async helpers
early head flush

The bad:

complicates, and in turn slows down the view system
graceful error reporting becomes much more difficult
promotes the use of a view for non-view-like computation

I have one simple reason why I need async view support: I need to read my view files asynchronously.  These files have many dependencies and subdependencies, which all need to be read when compiled.  It won't work with the current partial model.  I'm currently just bypassing the Express view rendering API, and outputting with res.send(), and using my own caching mechanism (needed for compile on demand dependencies).  Not using the Express view API means I can't use plugins for Express.  I currently have no problem outputting errors to the Express middleware, as I just catch them where relevant and pass them to req.next().  You know you have access to req from res.

express 3.x gets rid of partial(), and the engine signature is now engine.render(str, options, callback), which still wont be perfect for some engines since some templates wont live in files blah blah, so it's a leaky abstraction in that sense but it will never be a "nice" API and work for everything

may change the api though to something less obtrusive like engine.__express(str, options, callback) so if an engine like jade chooses to expose their regular jade.render it could just be exports.__express = exports.render or make modifications to comply with express as necessary

My only problem with that signature is that I would like to read in the files myself.  That is, I don't want to be passed a string, but rather a name, like 'page/new' or the full path to the file.

yeah we could go that route, it just slowly pushes more and more work on the engine, which is ok, im not against that, just letting everyone following this know. It may be the best route in the long-run, and now is the time to do it :D

Well, if you're getting rid of partial, then you probably want to move this to the engine.  You could then still decide to implement partial in your engine.

yup, it's nothing but a convenience to not have to redefine that sort of logic in each engine, but it would be a pretty small price to pay for greater abstraction so im fine with it

in master

I see only single unavoidable reason to introduce some async rendering like
res.renderAsync("viewName", data, (err) => next(err));
is to support async views, partials, and layouts loading andresoution from source other than local file system.
But for this the engines should have some facility to replace the view resolving, like dust.js has. Actually I almost never had support of async views loading or views names resolution like
engine.resolveView(name, (err, markup) => {})

authors: jupiter konstardiy visionmedia

repo: visionmedia/express


text:
Inverse ghost zone not working when all domains selected

Attached are two pictures of a simple mesh with inverse ghost zone operator applied. The only difference between the two pictures is that the one showing correct ghosting (somedomainoffcase) has one domain turned off. It doesn't matter which domain. Just one domain has to be off to get the correct ghost zones plotted. I suspect this has to do with optimization in the ghost zone and facelist filter for the all domains on case. I think alldomainsoninverseghostoperator has a problem. Perhaps the alldomainson optimization should be ignored when inverse-ghost-zone operator is in use?
-----------------------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: 3252
Status: Pending
Project: VisIt
Tracker: Bug
Priority: High
Subject: Inverse ghost zone not working when all domains selected
Assigned to: -
Category: -
Target version: 2.13.4
Author: Mark Miller
Start: 10/19/2018
Due date:
% Done: 0%
Estimated time:
Created: 10/19/2018 03:20 pm
Updated: 10/31/2018 07:12 pm
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: 2.13.2
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
Attached are two pictures of a simple mesh with inverse ghost zone operator applied. The only difference between the two pictures is that the one showing correct ghosting (somedomainoffcase) has one domain turned off. It doesn't matter which domain. Just one domain has to be off to get the correct ghost zones plotted. I suspect this has to do with optimization in the ghost zone and facelist filter for the all domains on case. I think alldomainsoninverseghostoperator has a problem. Perhaps the alldomainson optimization should be ignored when inverse-ghost-zone operator is in use?
Comments:
Here's the link to Randy's datahttps://visitbugs.ornl.gov/attachments/523/geosxSiloGhost.tar.7z

repo: visit-dav/visit


text:
Audit Plot3D read options for automation

The Plot3D reader has a number of options that kinda seem like they should just be automagically handled...

Iblanking...is there any reason VisIt should not iblank if the associated field is defined?
3D...is there any reason we can't effectiently detect this during open/popmd?
Big endian...is there nothing in the format itself that tells us this?
Double precision...for ascii isn't this meaningless and, again, is there no way to detect this?

If answers to all of the above are no, we cannot automate them then my next question is whether it makes sense for VisIt to define some additional keywords/keycodes in the format to support this and try to evangelize its use, similar to what we sometimes do with other formats (materials, expressions in VTK, mixed materials in Exodus, etc.)

Another option is the C vs. Fortran ordering (and maybe array indexing if that is relevant in Plot3D files).
One alternative to customizing the format is to defeine a json wrapper file like so...
{
    "ordering": "C",
    "3d": true,
    "precision": 4,
    "endian": "big",
    "path": "./foo.vp3d"
}

Any file VisIt is asked to open that has the original PLOT3D extensions (.q, .x or .vp3d) with a .json or maybe a -json following it would be processed similarly to options.
In fact, this might be a general way of handling this kind of thing in VisIt...Allow a json wrapper file to capture information the format itself doesn't conveniently define and then pass the json object down to the format.

Was this ticket made before the vp3d file was supported?

Was this ticket made before the vp3d file was supported?

Nope. This ticket was added April of this year and vp3d looks like it was added back in 2009.

Got it. Thanks for following up. I only ask because I believe VisIt already handles binary PLOT3D files automatically, and it seems like the .vp3d file, which the user can create himself, does what this ticket suggests.


text:
Remove recent change to internallauncher to unset LD_PRELOAD.

I user reported that our unsetting of LD_PRELOAD was causing problems in their environment. I propose removing the recent change and instead requiring that users make the change in their custom launcher. Here is the e-mail reporting the issue.
Eric,
I had a question for you on a new feature in VisIt 3.1.3, in its release notes it mentions.
"Modified the startup script to unsetenv LD_PRELOAD to protect against users setting it for the GL library, which would break rendering."
This new feature is negatively impacting us as we use LD_PRELOAD on our remote desktop systems.
These lines 2910-2911 of 3.1.3/bin/internallauncher
   # Unset LD_PRELOAD
    UNSETENV("LD_PRELOAD")

Where VisIt is now disabling LD_PRELOAD messes up our implementation and VisIt 3.1.3 running on our remote desktops. (no data is rendered)
I have found that the fix is disabling line 2911 of 3.1.3/bin/internallauncher
   # Unset LD_PRELOAD
   # UNSETENV("LD_PRELOAD")

VisIt 3.1.3 then functions properly again. (data is correctly rendered)
I have verified this issue on two of our systems and its fix.
Could you revert (remove) this feature? Or add a flag to disable this feature?
Thanks.

Closed via #5134.


text:
Internet Explorer support?

I am wondering if it's possible to get this supported in IE?

This?

Well, this JS library. As in network diagrams. Sorry for not being specific enough. It seems to work on Chrome, Edge, Firefox, Edge Chromium, just IE 11 not working. Was wondering if it's possible or not really?

IE11 is supported (see https://browserl.ist/?q=>+0.1%25+or+not+dead for all supported browsers and versions) and should work. Any example of this not working? Any errors?

This: https://github.com/EvotecIT/PSWriteHTML/blob/master/Examples/Example31-NestedTabs/Example30-NestedTabs.html
On the right side on first tab there's a diagram. The important thing is that PSWriteHTML generates "Local" files and most users use them from disk directly without any web server.

Does it work if you use https://github.com/Thomaash/vis-network/blob/peer-build/standalone/umd/vis-network.js instead of the version you're using now?

That one works... is it different than the one I use? Or just because I hosted it locally worked?

It uses core js 3 instead of the dated core js 2.

Right, I saw some esm.js errors. Is it hosted on any CDN?

Officially? No. But you can get it through https://raw.githack.com/.

Any ETA for official?

No ETA is set. @mojoaxel had some issues with it and didn't review it after they were addressed.
Maybe you could have a look at it this weekend @mojoaxel?

Maybe you could have a look at it this weekend @mojoaxel?

I just approved the changes.

Since IE support still doesn't seem to work, is it possible to reopen this?

Yeah, sure, this should be reopened.

ESM module system/loading is not supported by IE (even Version 11), but it is by Edge. Maybe that's the root of the issue?

The test version that @Thomaash provided worked in IE. That means it should be possible to get it up and running.

I think I finally figured out why there were so many weird and seemingly random issues. To put it shortly we were polyfilling polyfills (up to five layers of polyfills in the worst case) which is a really stupid thing to do. It sometimes fails, sometimes works and sometimes it obscures issues in underling packages.
There are three PRs opened right now addressing this and after they're merged and the updated packages are updated (this is a bit complicated process because we use dependency hell design pattern) it should work.

Will it potentially resolve my issues from https://github.com/visjs/vis-network/issues/139 ?

I copy pasted the code into a file and replaced the unpkg.com version with the one from my test build. Once the icon font is loaded/cached everything works as expected. Though was not able to reproduce your issue back then either.
Maybe it was polyfilling issue. Polyfills often depend on slight nuances to decide whether a polyfill should be applied or the native implementation used. It's possible that some polyfill failed due to this only in your environment but not in mine and caused the problem. Or maybe not. I really don't know.

We will see :-) Thank you!

Actually you can test it yourself right now: vis-network.zip.

No, no change.

This seems to work with 6.4.6. Thank you!

authors: PrzemyslawKlys Thomaash mojoaxel szabi

repo: visjs/vis-network


text:
🛑 Element Life is down

In 887f08b, Element Life (https://elemntlife.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Element Life is back up in 0d395e8.

repo: vistaardigital/uptime


text:
В версии 2.0 при экспорте, когда поле пустое возникает ошибка

Когда экспортирую, в режиме одного файла, и этого самого файла нет возникает ошибка
VI\MoonShineSpatieMediaLibrary\Fields\MediaLibrary::resolvePreview(): Return value must be of type Illuminate\Contracts\View\View|string, null returned
Предлагаемое решение в этом самом файле строка 34 заменить на : ($this->value?->getFullUrl() ?? '');

Добавил в версии https://github.com/visual-ideas/moonshine-spatie-medialibrary/releases/tag/2.0.4

authors: Mostok alexvenga


text:
Succes add alc 270 layout 10

AppleALC-master 3.zip
Here I'll share about my succes build the alc270 0x0100 using layout id 10. Hope u can share it

Hi
What did you change in this resources? Your revision-id is the same as in trunk. Did you made custom resources for this codec? I will not add unknown stuff in AppleALC without explanations. Provide description of what did you change, why and for what hardware.

Hi, I just added my Platfrom ALC270 sound for ASUS Laptop, because it not
same with resource in AppleALC file before and not working for me. So I
added it, and It's working to me. Some ASUS Laptop's user use AppleALC from
my Platfrom ALC270 and it's working for them. I asked to you to reupload
the new file who I have added the new platfrom ALC 270 using Layout 10. I
hope u can do it. Thanks
On Tue, Mar 27, 2018 at 11:59 PM, vandroiy2013 notifications@github.com
wrote:

Hi
What did you change in this resources? Your revision-id is the same as in
trunk. Did you made custom resources for this codec? I will not add unknown
stuff in AppleALC without explanations. Provide description of what did you
change, why and for what hardware.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vit9696/AppleALC/issues/259#issuecomment-376598877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AR4Uwepi9AVPdq-H3MeDLrNUNJYNOWUUks5tim_cgaJpZM4S6CFy
.


text:
How to conditionally execute registerSW & useRegisterSW based on different MODE?

I have multiple modes, such as mode=production for packaging to the web, and mode=tauri for packaging to the PC client.
I only want to enable PWA when packaging to the web, and not enable PWA when packaging to the PC client. So I added the following code:
main.js
import { registerSW } from 'virtual:pwa-register'
const updateSW = registerSW({
          onNeedRefresh() {
            // alert('prompt user to update')
          }
        })

vite.config.js
{
  plugins: [
    vue(),
    mode === 'production' && VitePWA({
      // ...
    }),
  ]
}

I cannot conditionally enable vite-plugin-pwa as configured in vite.config.ts above, otherwise it will throw an error: Importing "virtual:pwa-register" could not be resolved.
How should I conditionally execute registerSW and useRegisterSW based on different MODE?

check elk.repo, we have also Tauri app:

disable the plugin via env variable and using std-env: https://github.com/elk-zone/elk/blob/main/config/pwa.ts#L7
register tauri module before the pwa: https://github.com/elk-zone/elk/blob/main/nuxt.config.ts#L32
in tauri module just disable the option: https://github.com/elk-zone/elk/blob/main/modules/tauri/index.ts#L18

Hi, @userquin
Thanks for your reply.
What you showed is quite complicated, especially regarding the configuration environment of Nuxt. I'm not entirely sure how to simply move it to a regular Vite+Vue frontend project.
I'm considering whether to write the logic for registerSW and useRegisterSW in a Vue plugin, using the form createApp({}).use(pwaPlugin).
This way, I can determine whether to execute the logic based on environmental variables.
If it's not executed, the error of importing should not occur during the packaging process.
I'm not certain about this approach, but I plan to give it a try tomorrow.

https://github.com/vite-pwa/vite-plugin-pwa/blob/main/examples/vue-router/vite.config.ts#L45

@userquin thanks for your answer.
To be honest, I'm not quite sure where disabled:true should be written in the configuration parameter.
I saw that a type definition interface VitePluginPWAAPI is exposed, which has a disabled property. However, the function VitePWA, with its parameter VitePWAOptions, does not have the disabled attribute or the VitePluginPWAAPI type attribute.
The logic for the "disabled" parameter here comes from createAPI.https://github.com/vite-pwa/vite-plugin-pwa/blob/b8202760d924f458f4a8d8aa1e7cb3dc59a62327/src/index.ts#L10-L14
The logic for the "disabled" parameter here comes from ctx?.options.https://github.com/vite-pwa/vite-plugin-pwa/blob/b8202760d924f458f4a8d8aa1e7cb3dc59a62327/src/api.ts#L60-L62
The logic for the "disabled" parameter here comes from createContext.https://github.com/vite-pwa/vite-plugin-pwa/blob/b8202760d924f458f4a8d8aa1e7cb3dc59a62327/src/index.ts#L10-L12
The logic for "disabled" parameter here always get false.https://github.com/vite-pwa/vite-plugin-pwa/blob/b8202760d924f458f4a8d8aa1e7cb3dc59a62327/src/context.ts#L12-L20

To be honest, I'm not quite sure where disabled:true should be written in the configuration parameter.

It is disable, remove the final d: you need to override the configuration options, you cannot change the PWA  options once loaded.

I guess it should be done like this
vite.config.ts
{
  plugins: [
    vue(),
    {
      ...VitePWA({
        // ...
      }),
      disable: true
    }
  ]
}

I will give it a try tomorrow. Thank you for your guidance :heart:

repo: vite-pwa/vite-plugin-pwa


text:
docs: add server.proxy configuration

All credit goes to u/konstantinblaesi.
If the server.proxy is not set, the following error is shown in the browser.
TypeError: Could not convert argument of type symbol to string.
  at webidl.converters.DOMString (node:internal/deps/undici/undici:1977:15)
  at webidl.converters.ByteString (node:internal/deps/undici/undici:1982:35)
  at Object.record<ByteString, ByteString> (node:internal/deps/undici/undici:1894:30)
  at webidl.converters.HeadersInit (node:internal/deps/undici/undici:3424:67)
  at Object.RequestInit (node:internal/deps/undici/undici:1951:21)
  at new Request (node:internal/deps/undici/undici:4835:34)

Reproducible in the following environment.
Binaries:
  Node: 20.14.0 - ~/.local/state/fnm_multishells/43230_1718006277694/bin/node
  npm: 10.7.0 - ~/.local/state/fnm_multishells/43230_1718006277694/bin/npm
  pnpm: 9.2.0 - ~/.local/state/fnm_multishells/43230_1718006277694/bin/pnpm
npmPackages:
  @vitejs/plugin-basic-ssl: ^1.1.0 => 1.1.0
  vite: ^5.2.13 => 5.2.13
  vitest: ^1.6.0 => 1.6.0

No I don't. I just found a working workaround for this issue.
Should I close this PR and convert it into an issue?

Yeah I would close this for now. It's good that we have additional information on the web of this workaround. But I think it would be better if you can (or someone else) investigate the bug first and open the issue in the correct repo 🙏

authors: bluwy hyunbinseo

repo: vitejs/vite-plugin-basic-ssl


text:
Feature request: Add "include" and "exclude" option just like in @vitejs/plugin-react

Unfortunately, this package currently does not support "include" and "exclude" options just like in @vitejs/plugin-react

Hi!
What's the need/use case behind this?

@ArnaudBarre Hey, thanks for the reply. My use case is to exclude test files.
All my test files are under /src/__tests__ folder, using Vitest, and whenever I changed some test file, the dev server will refresh the page. So I want to exclude those files from triggering HMR.

This is not something that can be changed by a plugin. You can use https://vitejs.dev/config/server-options.html#server-watch to ignore test files.
Maybe we should change how files are watched by default, I will discuss this with the team.

@ArnaudBarre Hey, I've tried your suggestion but unfortunately, it won't work. It will disable the HMR for vitest as well.
Usually, we will write vitest config inside vite.config.ts so we don't need to repeat those shared configs like resolve.alias.
The only solution is to create another vitest.config.ts and copy those repeated configs, so server.watch.ignored won't apply to Vitest...
A little bit frustrating...

Technically you could share some config via a third file imported in both. But that's a bit frustrating I agree.
Are you using Tailwind? I think this could be the cause of the fact that test files triggers a refresh

Yeah exactly. I was wondering why it will trigger the refresh... Looking forward to hearing about what's happening under the hood if you have time.

The simple solution is to remove test from Tailwind content.
Here is a plugin I added to a project to solve this issue more globally for an SPA. Maybe this could be fixed in core but not sure we can have an exact list of entry points. You can thanks @liautaud for writing down this nice comment.
    {
      name: "fix-tailwind-page-reload",
      apply: "serve",
      /**
       * Fixes a bug in the interaction between Tailwind and Vite where creating
       * or editing un-imported or type-only TS files would trigger a full reload.
       *
       * In short, the issue is that Tailwind needs to listen to changes in all
       * TS files in development, which it accomplishes in a hacky way by adding
       * an edge between `index.css` and every TS file in the Vite dependency
       * graph–even if the file is otherwise un-imported or contains only types.
       *
       * This lead to a bug in Vite where TS or HTML files imported by no other
       * file were not being treated as entry-points because they were being
       * "implicitly" imported by `index.css`, which was mitigated in vite#3929
       * by treating files as entry-points if they are only being imported by
       * CSS files. Unfortunately, since the Vite dependency graph also contains
       * un-imported and type-only files, these get treated as entry-points too,
       * and so they trigger a full page reload.
       *
       * In our case, though, we know that the only entry-point is `index.tsx`,
       * so we can avoid the issue altogether by hooking into `handleHotUpdate`
       * (see https://vitejs.dev/guide/api-plugin.html#handlehotupdate) and
       * disabling full page reloads for "wrong" entry-points, i.e. files being
       * imported only by CSS files which are not `index.tsx`.
       */
      handleHotUpdate({ file, modules }) {
        if (
          modules.every((m) =>
            [...m.importers].every((i) => i.url.endsWith(".css")),
          ) &&
          !file.endsWith("src/index.tsx")
        ) {
          return [];
        }
      },

authors: ArnaudBarre xsjcTony

repo: vitejs/vite-plugin-react-swc


text:
From an optimization point of view, why not add the  tag like Solidjs

Description
considering the optimization direction of vue jsx, can you refer to solidjs and provide some tags that help engine optimization, just like solidjs.
Suggested solution
such as: {}
Alternative
No response
Additional context
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 request the same feature to avoid creating a duplicate.

I think feature requests for Vue JSX should be at https://github.com/vuejs/babel-plugin-transform-vue-jsx

authors: bluwy chaozwn

repo: vitejs/vite


text:
/public directory file loading error

Describe the bug
Use the js file in public path

run pnpm start

ERROR  Failed to load url /serverConfig.js (resolved id: /serverConfig.js). This file is in /public and will be copied as-is during build without going through the plugin transforms, and therefore should not be imported from source code. It can only be referenced via HTML tags.
Reproduction
null
Steps to reproduce
No response
System Info
System:
    OS: macOS 13.0
    CPU: (10) arm64 Apple M1 Pro
    Memory: 285.47 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.20.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.19.4 - /usr/local/bin/npm
    pnpm: 8.6.12 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 116.0.5845.96
    Safari: 16.1
  npmPackages:
    @vitejs/plugin-vue: ^4.1.0 => 4.1.0
    vite: ^4.4.9 => 4.4.9

Used Package Manager
pnpm
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.

Page running can load js normally.


text:
Execution of vite build fails on typescript decorators

Describe the bug
After transpiling using the vite command, then running the website hosted by vite (http://localhost:9000), the browser should not fail with this error in the console:

Uncaught SyntaxError SyntaxError: Invalid or unexpected token
at (program) (c:[...]\src\pages\resume\resume.ts:18:1)

The line of code is a decorator in resume.ts.
I expect the transpiled code to understand what to do with decorators.
Note that the tsconfig.js compilerOption section does not include:
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,

but those should not be necessary given the decorator implementation (Aurelia) I am using, and the versions:
"esbuild": "^0.21.3",
"typescript": "5.4.5",

If one adds in those two tsconfig compilerOption lines, then the vite problem disappears but then a different browser error ensues because the esbuild and typescript revisions require those options to be removed or set to false in order for decorators to work.
So I wonder whether vite has fallen behind these new revisions regarding decorators, or if there is something I need to do to get vite to work in this scenario?  Is vite usually expected to work in this scenario?
Reproduction
https://github.com/dkent600/douglaskent/tree/decorators-issue
Steps to reproduce
Steps:

clone https://github.com/dkent600/douglaskent/tree/decorators-issue
run npm install
run npm debug or npx vite
browse to http://localhost:9000/
see the error message in the console.log

"esbuild": "^0.21.3",
"typescript": "5.4.5",
"vite": "5.2.11",

System Info
System:
    OS: Windows 11 10.0.22631
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i7-12700H
    Memory: 15.24 GB / 31.68 GB
  Binaries:
    Node: 20.12.1 - C:\Program Files\nodejs\node.EXE
    npm: 10.5.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (123.0.2420.97)
    Internet Explorer: 11.0.22621.3527
  npmPackages:
    vite: 5.2.11 => 5.2.11

Used Package Manager
npm
Logs

Click to expand!$ npx vite --debug
  vite:config bundled config file loaded in 728.76ms +0ms
  vite:config using resolved config: {
  vite:config   server: {
  vite:config     preTransformRequests: true,
  vite:config     port: 9000,
  vite:config     strictPort: true,
  vite:config     sourcemapIgnoreList: [Function: isInNodeModules$1],
  vite:config     middlewareMode: false,
  vite:config     fs: {
  vite:config       strict: true,
  vite:config       allow: [Array],
  vite:config       deny: [Array],
  vite:config       cachedChecks: undefined
  vite:config     }
  vite:config   },
  vite:config   build: {
  vite:config     target: 'es2022',
  vite:config     cssTarget: 'es2022',
  vite:config     outDir: 'dist',
  vite:config     assetsDir: 'assets',
  vite:config     assetsInlineLimit: 4096,
  vite:config     cssCodeSplit: true,
  vite:config     sourcemap: false,
  vite:config     rollupOptions: { plugins: [Array] },
  vite:config     minify: 'terser',
  vite:config     terserOptions: {},
  vite:config     write: true,
  vite:config     emptyOutDir: null,
  vite:config     copyPublicDir: true,
  vite:config     manifest: false,
  vite:config     lib: false,
  vite:config     ssr: false,
  vite:config     ssrManifest: false,
  vite:config     ssrEmitAssets: false,
  vite:config     reportCompressedSize: true,
  vite:config     chunkSizeWarningLimit: 500,
  vite:config     watch: null,
  vite:config     commonjsOptions: {
  vite:config       include: [Array],
  vite:config       extensions: [Array],
  vite:config       transformMixedEsModules: true
  vite:config     },
  vite:config     dynamicImportVarsOptions: { warnOnError: true, exclude: [Array] },
  vite:config     modulePreload: { polyfill: true },
  vite:config     cssMinify: true
  vite:config   },
  vite:config   plugins: [
  vite:config     'vite:optimized-deps',
  vite:config     'vite:watch-package-data',
  vite:config     'vite:pre-alias',
  vite:config     'alias',
  vite:config     'au2',
  vite:config     'sass-glob-import',
  vite:config     'vite:modulepreload-polyfill',
  vite:config     'vite:resolve',
  vite:config     'vite:html-inline-proxy',
  vite:config     'vite:css',
  vite:config     'vite:esbuild',
  vite:config     'vite:json',
  vite:config     'vite:wasm-helper',
  vite:config     'vite:worker',
  vite:config     'vite:asset',
  vite:config     'aurelia:dev-alias',
  vite:config     'raw',
  vite:config     'visualizer',
  vite:config     'vite:wasm-fallback',
  vite:config     'vite:define',
  vite:config     'vite:css-post',
  vite:config     'vite:worker-import-meta-url',
  vite:config     'vite:asset-import-meta-url',
  vite:config     'vite:dynamic-import-vars',
  vite:config     'vite:import-glob',
  vite:config     'vite:client-inject',
  vite:config     'vite:css-analysis',
  vite:config     'vite:import-analysis'
  vite:config   ],
  vite:config   define: {
  vite:config     'process.env': {
  vite:config       ALLUSERSPROFILE: 'C:\\ProgramData',
  vite:config       APPDATA: 'C:\\Users\\dkent\\AppData\\Roaming',
  vite:config       CHROME_CRASHPAD_PIPE_NAME: '\\\\.\\pipe\\crashpad_12084_MBWYNBPZXEFMYLCW',
  vite:config       COLOR: '1',
  vite:config       COLORTERM: 'truecolor',
  vite:config       CommonProgramFiles: 'C:\\Program Files\\Common Files',
  vite:config       'CommonProgramFiles(x86)': 'C:\\Program Files (x86)\\Common Files',
  vite:config       CommonProgramW6432: 'C:\\Program Files\\Common Files',
  vite:config       COMPUTERNAME: 'PATRICIA',
  vite:config       ComSpec: 'C:\\WINDOWS\\system32\\cmd.exe',
  vite:config       DEBUG: 'vite:*',
  vite:config       DriverData: 'C:\\Windows\\System32\\Drivers\\DriverData',
  vite:config       EDITOR: 'C:\\WINDOWS\\notepad.exe',
  vite:config       EFC_10792: '1',
  vite:config       FPS_BROWSER_APP_PROFILE_STRING: 'Internet Explorer',
  vite:config       FPS_BROWSER_USER_PROFILE_STRING: 'Default',
  vite:config       GIT_ASKPASS: 'c:\\Users\\dkent\\AppData\\Local\\Programs\\Microsoft VS Code\\resources\\app\\extensions\\git\\dist\\askpass.sh',
  vite:config       HOME: 'C:\\Users\\dkent',
  vite:config       HOMEDRIVE: 'C:',
  vite:config       HOMEPATH: '\\Users\\dkent',
  vite:config       IGCCSVC_DB: 'AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAA6VSUXuZ5jEu8aMRy3IoifQQAAAACAAAAAAAQZgAAAAEAACAAAAANAClIoaC9Ke90bBHD4hGMxFIFLW6K/is+JxdCWc4jAwAAAAAOgAAAAAIAACAAAABrcxv/8a1QNRHZM6ryyvW3Z2q1e7tOztg672KxZBOrDmAAAABwmIFcbImsQeyjMLIXx9crgmzWy4x9ncGsiofazx/Ee6CsO/J+h9y2MG/OioMvbk3dxwi48djoldnN3Cy7DmgzRhHwIhM6AK/J0ZG5j16aUWmOkmJpXw1AmI8Jsq66Ky9AAAAAqTBYOXIB/3D6c0s9ZMnpkfI8lnLFeyQdUzQtVKE7yPlWfBng2/lacGdNp/yA3ALZD2cYKsqn54VuvkIyhLjm5A==',
  vite:config       INIT_CWD: 'C:\\Users\\dkent\\Documents\\Projects\\douglaskent',
  vite:config       LANG: 'en_US.UTF-8',
  vite:config       LOCALAPPDATA: 'C:\\Users\\dkent\\AppData\\Local',
  vite:config       LOGONSERVER: '\\\\PATRICIA',
  vite:config       NODE: 'C:\\Program Files\\nodejs\\node.exe',
  vite:config       NODE_ENV: 'development',
  vite:config       NODE_EXE: 'C:\\Program Files\\nodejs\\\\node.exe',
  vite:config       NPM_CLI_JS: 'C:\\Program Files\\nodejs\\\\node_modules\\npm\\bin\\npm-cli.js',
  vite:config       npm_command: 'exec',
  vite:config       npm_config_auto_install_peers: 'true',
  vite:config       npm_config_cache: 'C:\\Users\\dkent\\AppData\\Local\\npm-cache',
  vite:config       npm_config_globalconfig: 'C:\\Program Files\\nodejs\\etc\\npmrc',
  vite:config       npm_config_global_prefix: 'C:\\Program Files\\nodejs',
  vite:config       npm_config_init_module: 'C:\\Users\\dkent\\.npm-init.js',
  vite:config       npm_config_local_prefix: 'C:\\Users\\dkent\\Documents\\Projects\\douglaskent',
  vite:config       npm_config_msvs_version: '',
  vite:config       npm_config_node_gyp: 'C:\\Users\\dkent\\AppData\\Roaming\\nvm\\v20.12.1\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js',
  vite:config       npm_config_noproxy: '',
  vite:config       npm_config_npm_version: '10.5.0',
  vite:config       npm_config_prefix: 'C:\\Program Files\\nodejs',
  vite:config       npm_config_shamefully_hoist: 'true',
  vite:config       npm_config_unsafe_perm: 'true',
  vite:config       npm_config_userconfig: 'C:\\Users\\dkent\\.npmrc',
  vite:config       npm_config_user_agent: 'npm/10.5.0 node/v20.12.1 win32 x64 workspaces/false',
  vite:config       npm_execpath: 'C:\\Users\\dkent\\AppData\\Roaming\\nvm\\v20.12.1\\node_modules\\npm\\bin\\npm-cli.js',
  vite:config       npm_lifecycle_event: 'npx',
  vite:config       npm_lifecycle_script: 'vite',
  vite:config       npm_node_execpath: 'C:\\Program Files\\nodejs\\node.exe',
  vite:config       npm_package_json: 'C:\\Users\\dkent\\Documents\\Projects\\douglaskent\\package.json',
  vite:config       npm_package_version: '1.2',
  vite:config       NPM_PREFIX_NPX_CLI_JS: 'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npx-cli.js',
  vite:config       NPX_CLI_JS: 'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npx-cli.js',
  vite:config       NUMBER_OF_PROCESSORS: '20',
  vite:config       NVM_HOME: 'C:\\Users\\dkent\\AppData\\Roaming\\nvm',
  vite:config       NVM_SYMLINK: 'C:\\Program Files\\nodejs',
  vite:config       OneDrive: 'C:\\Users\\dkent\\OneDrive',
  vite:config       OneDriveConsumer: 'C:\\Users\\dkent\\OneDrive',
  vite:config       ORIGINAL_XDG_CURRENT_DESKTOP: 'undefined',
  vite:config       OS: 'Windows_NT',
  vite:config       Path: 'C:\\Users\\dkent\\Documents\\Projects\\douglaskent\\node_modules\\.bin;C:\\Users\\dkent\\Documents\\Projects\\douglaskent\\node_modules\\.bin;C:\\Users\\dkent\\Documents\\Projects\\node_modules\\.bin;C:\\Users\\dkent\\Documents\\node_modules\\.bin;C:\\Users\\dkent\\node_modules\\.bin;C:\\Users\\node_modules\\.bin;C:\\node_modules\\.bin;C:\\Users\\dkent\\AppData\\Roaming\\nvm\\v20.12.1\\node_modules\\npm\\node_modules\\@npmcli\\run-script\\lib\\node-gyp-bin;C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.4.2.0_x64__8wekyb3d8bbwe;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Windows\\System32\\OpenSSH\\;C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common;C:\\Program Files\\NVIDIA Corporation\\NVIDIA NvDLISR;C:\\Program Files\\dotnet\\;C:\\Program Files\\Git\\cmd;C:\\Users\\dkent\\AppData\\Roaming\\nvm;C:\\Program Files\\nodejs;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\WINDOWS\\System32\\OpenSSH\\;C:\\Program Files\\Cloudflare\\Cloudflare WARP\\;C:\\Program Files\\Docker\\Docker\\resources\\bin;C:\\Users\\dkent\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\dkent\\AppData\\Local\\Programs\\Microsoft VS Code\\bin;C:\\Users\\dkent\\AppData\\Local\\gitkraken\\bin;C:\\Users\\dkent\\AppData\\Roaming\\nvm;C:\\Program Files\\nodejs;C:\\Users\\dkent\\AppData\\Local\\Microsoft\\WindowsApps;',
  vite:config       PATHEXT: '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.CPL',
  vite:config       PROCESSOR_ARCHITECTURE: 'AMD64',
  vite:config       PROCESSOR_IDENTIFIER: 'Intel64 Family 6 Model 154 Stepping 3, GenuineIntel',
  vite:config       PROCESSOR_LEVEL: '6',
  vite:config       PROCESSOR_REVISION: '9a03',
  vite:config       ProgramData: 'C:\\ProgramData',
  vite:config       ProgramFiles: 'C:\\Program Files',
  vite:config       'ProgramFiles(x86)': 'C:\\Program Files (x86)',
  vite:config       ProgramW6432: 'C:\\Program Files',
  vite:config       PROMPT: '$P$G',
  vite:config       PSModulePath: 'C:\\Users\\dkent\\OneDrive\\Documents\\PowerShell\\Modules;C:\\Program Files\\PowerShell\\Modules;c:\\program files\\windowsapps\\microsoft.powershell_7.4.2.0_x64__8wekyb3d8bbwe\\Modules;C:\\Program Files\\WindowsPowerShell\\Modules;C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\Modules',
  vite:config       PUBLIC: 'C:\\Users\\Public',
  vite:config       SESSIONNAME: 'Console',
  vite:config       SystemDrive: 'C:',
  vite:config       SystemRoot: 'C:\\WINDOWS',
  vite:config       TEMP: 'C:\\Users\\dkent\\AppData\\Local\\Temp',
  vite:config       TERM_PROGRAM: 'vscode',
  vite:config       TERM_PROGRAM_VERSION: '1.89.1',
  vite:config       TMP: 'C:\\Users\\dkent\\AppData\\Local\\Temp',
  vite:config       USERDOMAIN: 'PATRICIA',
  vite:config       USERDOMAIN_ROAMINGPROFILE: 'PATRICIA',
  vite:config       USERNAME: 'dkent',
  vite:config       USERPROFILE: 'C:\\Users\\dkent',
  vite:config       VSCODE_GIT_ASKPASS_EXTRA_ARGS: '',
  vite:config       VSCODE_GIT_ASKPASS_MAIN: 'c:\\Users\\dkent\\AppData\\Local\\Programs\\Microsoft VS Code\\resources\\app\\extensions\\git\\dist\\askpass-main.js',
  vite:config       VSCODE_GIT_ASKPASS_NODE: 'C:\\Users\\dkent\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe',
  vite:config       VSCODE_GIT_IPC_HANDLE: '\\\\.\\pipe\\vscode-git-08740befd1-sock',
  vite:config       VSCODE_INJECTION: '1',
  vite:config       windir: 'C:\\WINDOWS',
  vite:config       ZES_ENABLE_SYSMAN: '1'
  vite:config     }
  vite:config   },
  vite:config   resolve: {
  vite:config     mainFields: [ 'browser', 'module', 'jsnext:main', 'jsnext' ],
  vite:config     conditions: [],
  vite:config     extensions: [
  vite:config       '.mjs',  '.js',
  vite:config       '.mts',  '.ts',
  vite:config       '.jsx',  '.tsx',
  vite:config       '.json'
  vite:config     ],
  vite:config     dedupe: [],
  vite:config     preserveSymlinks: false,
  vite:config     alias: [ [Object], [Object], [Object] ]
  vite:config   },
  vite:config   optimizeDeps: {
  vite:config     holdUntilCrawlEnd: true,
  vite:config     esbuildOptions: {
  vite:config       preserveSymlinks: false,
  vite:config       target: 'es2022',
  vite:config       define: [Object],
  vite:config       plugins: [Array]
  vite:config     }
  vite:config   },
  vite:config   configFile: 'C:/Users/dkent/Documents/Projects/douglaskent/vite.config.ts',
  vite:config   configFileDependencies: [ 'C:/Users/dkent/Documents/Projects/douglaskent/vite.config.ts' ],
  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     optimizeDeps: { force: undefined },
  vite:config     server: { host: undefined }
  vite:config   },
  vite:config   root: 'C:/Users/dkent/Documents/Projects/douglaskent',
  vite:config   base: '/',
  vite:config   rawBase: '/',
  vite:config   publicDir: 'C:/Users/dkent/Documents/Projects/douglaskent/public',
  vite:config   cacheDir: 'C:/Users/dkent/Documents/Projects/douglaskent/node_modules/.vite',
  vite:config   command: 'serve',
  vite:config   mode: 'development',
  vite:config   ssr: {
  vite:config     target: 'node',
  vite:config     optimizeDeps: { noDiscovery: true, esbuildOptions: [Object] }
  vite:config   },
  vite:config   isWorker: false,
  vite:config   mainConfig: null,
  vite:config   bundleChain: [],
  vite:config   isProduction: false,
  vite:config   css: { lightningcss: undefined },
  vite:config   esbuild: { jsxDev: true },
  vite:config   preview: {
  vite:config     port: undefined,
  vite:config     strictPort: true,
  vite:config     host: undefined,
  vite:config     https: undefined,
  vite:config     open: undefined,
  vite:config     proxy: undefined,
  vite:config     cors: undefined,
  vite:config     headers: undefined
  vite:config   },
  vite:config   envDir: 'C:/Users/dkent/Documents/Projects/douglaskent',
  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(1) {
  vite:config     'fnpd_C:/Users/dkent/Documents/Projects/douglaskent' => {
  vite:config       dir: 'C:/Users/dkent/Documents/Projects/douglaskent',
  vite:config       data: [Object],
  vite:config       hasSideEffects: [Function: hasSideEffects],
  vite:config       webResolvedImports: {},
  vite:config       nodeResolvedImports: {},
  vite:config       setResolvedCache: [Function: setResolvedCache],
  vite:config       getResolvedCache: [Function: getResolvedCache]
  vite:config     },
  vite:config     set: [Function (anonymous)]
  vite:config   },
  vite:config   createResolver: [Function: createResolver],
  vite:config   worker: { format: 'iife', plugins: '() => plugins', rollupOptions: {} },
  vite:config   appType: 'spa',
  vite:config   experimental: { importGlobRestoreExtension: false, hmrPartialAccept: false },
  vite:config   getSortedPlugins: [Function: getSortedPlugins],
  vite:config   getSortedPluginHooks: [Function: getSortedPluginHooks]
  vite:config } +30ms
  vite:deps Hash is consistent. Skipping. Use --force to override. +0ms

  VITE v5.2.11  ready in 1073 ms

  ➜  Local:   http://localhost:9000/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

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.

Are you getting the error from your browser, or your nodejs terminal? Vite doesn't down-level your code by default, so while it can parse the decorators, the output still keep it intact and send it to your browser, and your browser may not be able to parse decorators. When experimentalDecorators: true is set, esbuild will then down-level it because of different decorator semantics.
If you want to down-level the decorators to something else, you can configure esbuild.target: "es2022" or configure esbuild.supported.decorators: false.

@bluwy Thanks for your response!
To answer your questions:
You made me realize I misrepresented the case.  Rather than the error being issued from the compiler, it is issuing from the browser and one sees the error in the console.log.  I have modified the issue description accordingly.  Apologies.
Can you please confirm exactly what vite should be doing, given the scenario of this issue which is using the latest updates wrt to decorators:
in tsconfig.json and in vite.config:
    "module": "es2022",
    "target": "es2022",

esbuild is everywhere set to 0.21.3 (the latest)
typescript is set to 5.4.5 (the latest)
My understanding is that both emitDecoratorMetadata and experimentalDecorators should be false in this scenario and the decorators I am using (from Aurelia) are expecting this scenario.
Thanks!

Looks like esbuild and typescript differed.
I thought vite uses tsc on .ts files, apparently I was wrong. It looks like it's the esbuild for that work.
With tsc, experimentalDecorators is only needed for legacy decorator, tsc automatically deals with latest decorator. While esbuild requires experimentalDecorators to be set regardless.
Since decorator has not been natively implemented in browsers, I am not sure why esbuild doesn't touch it by default.

dkent600 and I use the same framework (Aurelia) and I think it is important to mention that decorators on classes are properly handled. It results in a static property that gives the information written in the decorator. For instance, @inject(Bar, Baz) annotation on a class named Foo results in:
Reflect.defineProperty(Foo, "inject", { value: [Bar, Baz], writable: true, configurable: true, enumerable: true });

with or without "experimentalDecorators": true
The problem occurs when decorator is on a method or on a field. Without experimentalDecorators the decorator is in the js file and the browser complains (since he @ is an illegal character). With experimentalDecorators=true the decorator is transform in js code that fails (framework error). More details about this transformation:
ts source file of class Foo:
s = "";
@watch("s")
onchange(newValue: any){
    console.log("hello")
}

js code:
__decorateClass([
  watch("s")
], Foo.prototype, "onchange", 1);

I assume this has to wait for #16616.

I forgot to mention that overriding the esbuild version :
"overrides": {
    "vite": {
      "esbuild": "0.21.4"
    }
  }

and/or settings "target": "ES2022" (or esnext) in tsconfig.json does not solves the problem.

Can you please confirm exactly what vite should be doing, given the scenario of this issue which is using the latest updates wrt to decorators:

@dkent600 esbuild has two ways to set the transform target: its target top-level option, and tsconfigRaw.compilerOptions.target option (from tsconfig.json). The former Vite sets as esnext and esbuild will prioritize that over tsconfigRaw. This is documented at https://vitejs.dev/guide/features.html#target. experimentalDecorators is not needed.
As mentioned, you need to set this to work:

If you want to down-level the decorators to something else, you can configure esbuild.target: "es2022" or configure esbuild.supported.decorators: false.

However, I noticed that this also requires esbuild v0.21 to work so esbuild can compile it. As mentioned by others, you can use overrides to change the version that Vite uses. The upgrade is tracked at https://github.com/vitejs/vite/issues/16616

Indeed, setting target (es2020 for instance) in vite.config.json solves the problem.

Indeed, setting target (es2020 for instance) in vite.config.json solves the problem.

Cheers! To be clear, the solution is the target setting in vite config, plus esbuild 0.21 override?

Indeed, setting target (es2020 for instance) in vite.config.json solves the problem.

@ah1508 The code that I submitted to this issue demonstrating the problem is already using esbuild.target: "es2022" in vite.config and "overrides": { "esbuild": "^0.21.3" } in package.json.
These do not solve the problem, they demonstrate it.  Maybe I am misunderstanding something?

The code that I submitted to this issue demonstrating the problem is already using esbuild.target: "es2022" in vite.config and "overrides": { "esbuild": "^0.21.3" } in package.json.

It doesn't seem so? It's setting optimizeDeps.esbuildOptions.target: "es2022", not esbuild.target: "es2022"

I confirmed the repo works with esbuild.target: "es2022", plus esbuild 0.21.3 override in package.json. Needs both.

I confirmed the repo works with esbuild.target: "es2022", plus esbuild 0.21.3 override in package.json. Needs both.

You mean optimizeDeps.esbuildOptions.target: "es2022", yes?
That is exactly what the repository that I supplied to this issue is and has been using all along, and following the repo steps, it doesn't work, the browser continues to fail on decorators.  It seems @3cp that you are doing something different or are not following the repo steps.  How can we figure this out?

No, something like that:
/** @type {import('vite').UserConfig} */
export default {
    esbuild: {
        target: "es2020"
    },
    plugins: [/*your plugins*/]
}

The above config was what worked.
The vite fix was also release. I am working on an vite skeleton for au2, you can try it now from the branch (not merged yet).
npx makes aurelia/new#vite

Got some issue with css-module and vitest combination. If you don't use css-module, it should work smoothly.

esbuild: {
        target: "es2022"
    },

Yes @3cp !  I have confirmed that works, thanks! It looks like I have had some confusion interpreting the messages about what specifically was being called for here.

The vite fix was also release

@3cp The most recent vite release had no effect on the problem.  Finally only the specific "es2022" config change had any effect.

The vite fix was also release. I am working on an vite skeleton for au2, you can try it now from the branch (not merged yet).

Branch of what?

The target config is required for esbuild. The vite fix was upgrading to latest esbuild version, means you don't need override esbuild in package.json.


text:
Missing components and assets

[x] Read the docs.
[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] This is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

Describe the bug
I was being able to do a functional build with vite@1 and now that I have updated my configuration and my modules to work with vite@2, some assets and components do not load correctly and have paths that do not correspond to the real absolute paths.
It works perfect on dev and although I am making an app with electron, it should not be a problem since as I mentioned before the builds were good with vite@1.
It is not a problem with the assets, they exist in the build folder. Seems to be a problem when they are required.
This is a more detailed issue where you can find all the error messages and screenshots:
https://github.com/MangoTsing/vite-electron-quick/issues/11

Although I don't think it has to do with electron, again. Still I put it on vite-electron-quick to rule out the possibility.

This is my vite config:
import { join } from 'path'
import { UserConfig } from 'vite'
import dotenv from 'dotenv'
import vue from '@vitejs/plugin-vue'

dotenv.config({ path: join(__dirname, '.env') })
const root = join(__dirname, 'src/render')

const config: UserConfig = {
  root,
  resolve: {
    alias: {
      '/@/': root,
    }
  },
  base: './',
  build: {
    outDir: join('../../dist/render'),
    emptyOutDir: true,
    assetsInlineLimit: 0
  },
  server: {
    port: +process.env.PORT,
  },
  plugins: [
    vue()
  ],
  optimizeDeps: {
    exclude: [
      'electron-is-dev',
      'electron-store',
    ]
  },
}

export default config

Reproduction
https://github.com/denyncrawford/mismor-guillotine
A reproduction is required unless you are absolutely sure that the the problem is obvious and the information you provided is enough for us to understand what the problem is. If a report has only vague description (e.g. just a generic error message) and has no reproduction, it will receive "need reproduction" label. If no reproduction is provided after 3 days, it will be auto-closed.
System Info

vite latest:
Operating System: Windows 10 2004
Node version: 15.2.0
Package manager (npm) and version: 7.0.8

Check out https://vitejs.dev/guide/migration.html#alias-behavior-change, I think this may be the issue here. I'm closing this one as it is pointing to an old version of Vite. If your issue still persists, please create a new bug report against the latest Vite version. Try to isolate the issue in a minimal reproduction, thanks!

authors: denyncrawford patak-js


text:
load page is too lang

Describe the bug
When i use UI Framework in my projects,I import the css and run my app ,The browser load the css is too lang.
Reproduction
import 'ant-design-vue/dist/antd.css';
import 'tailwindcss/tailwind.css';
System Info
System:
    OS: macOS 11.4
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Memory: 178.13 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.17.0 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.13 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 91.0.4472.114
    Safari: 14.1.1

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.

It won't take too long if you are just importing these 2 CSS files.
On my machine:

Initial:

Reload:

Please provide a full reproduction so that we can diagnose the issue.

I tried it again and it still works the same way

Please provide a full reproduction. My guess is that you've accidentally put the import statements inside an another style file that requires heavy compilation.

I think the reason is tailwindcss. I have done the following experiments
Setp 1. I use the tailwindcss in my Projects at initial is slowly.but reload is normal.
Setp 2. Initial and reload is normal.
Use tailwindcss
Initial

Reload

Not tailwindcss
Initial

Reload

authors: huyanhai sodatea


text:
import.meta.hot does not exist in .ts files

Describe the bug
When using .js files, import.meta.hot exists and works. However, if I change the file to a TS file (and modify everything that imports this file accordingly), hot no longer exists on import.meta (the only property is import.meta.url). Moreover, even my VSCode intellisense shows the methods on import.meta.hot in a JS file, but in a TS file, it shows that property 'hot' does not exist on type 'ImportMeta'. I am not sure if this is expected behavior or a mistake on my part. I also can't tell if this is related to #503
Reproduction
Reproduction link: here.
Reproduction for the issue seems pretty straightforward, but I provided a reproduction repo anyway. To see the issue, change store.js to a .ts file, and update the store's import in main.js and module1.js to import store from './store'. Then reload the page and make a change to store.ts to see the issue.
NOTE: You can run the exact same test with module1.js (converting it to .ts, updating imports, reloading the page, and trying to make a change to the file).
System Info

required vite version: 1.0.0-beta.11
required Operating System: Windows 10
required Node version: 12.18.2
Optional:

npm/yarn version: 1.22.4
Installed vue version (from yarn.lock or package-lock.json): vue@^3.0.0-beta.20
Installed @vue/compiler-sfc version: @vue/compiler-sfc@^3.0.0-beta.20

See https://github.com/vitejs/vite/issues/416.

authors: shanrauf underfin


text:
vite production build

Describe the bug
Hello,
After vite build command every thing working fine but when I run dist index.html file ( production build )
( http://localhost/assets/index.694f5e13.js       404 Not Found )

Reproduction
Sorry, I don't know about Reproduction ?
System Info
System:
    OS: Windows 10 10.0.22000
    CPU: (8) x64 Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz
    Memory: 769.24 MB / 7.84 GB
  Binaries:
    Node: 16.13.2 - C:\Program Files\nodejs\node.EXE
    npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22000.120.0), Chromium (98.0.1108.50)
    Internet Explorer: 11.0.22000.120
  npmPackages:
    @vitejs/plugin-vue: ^2.1.0 => 2.2.2
    vite: ^2.7.13 => 2.8.4

Used Package Manager
npm
Logs
no error in logs

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.

I have been facing this issue myself

@iMiebaka please open another issue with a minimal reproduction. Thanks!

authors: GanpatJangra iMiebaka patak-dev


text:
:deep(<inner-selector>) on vue 2 is not working

Describe the bug
Hello,
When using the :deep selector inside a Vue 2 single file component's scoped style, such as:
<style scoped>
:deep(.app-child__hello) {
    color: red;
}
</style>

It will generate the given style:
[data-v-7ba5bd90]:deep(.app-child__hello) {
    color: red;
}

Instead of the following:
[data-v-7ba5bd90] .app-child__hello {
    color: red;
}

Using Webpack this example code is working fine. Using CSS or SCSS for the style of the Vue component won't change anything.
I don't know if this related to Vue, Vite or Vite Vue2 plugin so I'm creating an issue here as a starter.
Reproduction
https://github.com/paul-thebaud/vue-deep-bug
System Info
System:
    OS: Linux 5.15 Ubuntu 22.04 LTS 22.04 LTS (Jammy Jellyfish)
    CPU: (12) x64 AMD Ryzen 5 4600H with Radeon Graphics
    Memory: 2.05 GB / 15.01 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 1.22.15 - ~/.nvm/versions/node/v16.14.0/bin/yarn
    npm: 8.5.4 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 103.0.5060.53
    Firefox: 102.0
  npmPackages:
    vite: ^2.9.13 => 2.9.13

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 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.

:deep is supported by Vue3 but not by Vue2.6. ::v-deep should be used instead.
Also these are handled by the plugin so if I'm wrong please create the issue at https://github.com/underfin/vite-plugin-vue2.

Thanks a lot for this quick answer @sapphi-red, I asked on the plugin repository :smile:

authors: paul-thebaud sapphi-red


text:
fix: provide types for import.meta.env

Description
Closes https://github.com/vitejs/vite/issues/9539
I don't know if this is the ideal fix, but I've been banging my head against the wall for almost a full day to get this far. Hopefully someone a bit more versed in TypeScript can get this over the finish line if there's a better way to do this
Additional context
We're getting build failures on https://github.com/sveltejs/kit/pull/10187 because of this issue

What is the purpose of this pull request?

[X] Bug fix
[ ] 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 PR Title 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.

Isn't this way the correct method for using vite/client? I don't think this is the right fix.

Opened the repro and it looks like a dts-buddy bug to me.
packages/kit/src/exports/public.d.ts
import 'svelte'; // pick up `declare module "*.svelte"`
import 'vite/client'; // pick up `declare module "*.jpg"`, etc.
import '../types/ambient.js';

import { CompileOptions } from 'svelte/types/compiler/interfaces';
// ...

packages/kit/types/index.d.ts
declare module '@sveltejs/kit' {
	// !! The imports here are gone
	import type { CompileOptions } from 'svelte/types/compiler/interfaces';
	import type { PluginOptions } from '@sveltejs/vite-plugin-svelte';
// ...

Adding import 'vite/client' manually there fixes the issue.

Aha! Thank you for figuring out why it broke all of a sudden
I'm still rather perplexed by the intended usage of vite/client though. Maybe it's just a documentation issue. There's currently a thread in the Vite Discord, so maybe easier to discuss there.

authors: benmccann bluwy


text:
fix(config): deno resolving vite cjs entry

Description
The CJS detection logic that checks whether the CJS entry of vite itself is used is based around package.json detection. With Deno this assumption is not true anymore as most Deno projects don't have a package.json file. Instead they either have a deno.json or a deno.jsonc file. Projects in Deno are always in ESM too.
When using vite in Deno you'd always see this warning unless you added a package.json with type: module:

Ultimately, this is caused by the check here https://github.com/vitejs/vite/blob/35cf59c9d53ef544eb5f2fe2f9ff4d6cb225e63b/packages/vite/src/node/utils.ts#L430
Which infers that the current project is in CJS. This PR addresses that by making vite aware of Deno projects. When running inside Deno, we'll not just check for package.json, but also deno.json and deno.jsonc too.

I'm not too familiar with the testing setup here in vite and would need some pointers for adding a test. Where do these go here?
Fixes https://github.com/denoland/deno/issues/25574

findNearestPackageData is a hot spot and probably should avoid adding fs accesses if possible.
Does having deno.json/deno.jsonc in node_modules change the behavior?
If not, I wonder if we can change this line
https://github.com/vitejs/vite/blob/35cf59c9d53ef544eb5f2fe2f9ff4d6cb225e63b/packages/vite/src/node/config.ts#L1511
to
const isESM = process.versions.deno || isFilePathESM(resolvedPath)

instead.

Thanks for the tip! I had a feeling that putting the check in findNearestPackageData wasn't the right place. You suggestion of putting it in the config loading logic is much better. Updated the PR.

authors: marvinhagemeister sapphi-red


text:
refactor: remove the need for "processSourceMap"

Description
This PR move the logic that fixes the source maps in the module runner to the evaluator.
The evaluator is the reason why we need this change, so it makes sense that it will the one controlling it.

/ecosystem-ci run

/ecosystem-ci run

authors: patak-dev sheremet-va


text:
chore: don't publish sourcemaps

Avoid publishing inline sourcemaps to npm, just like Vite

ok I think that's all of them

What's the benefit of not publishing it? I actually did that on purpose.

@antfu It increases the install size by a lot. Vite also used to publish sourcemaps, but stopped. Anyone debugging Vitest can fork the repo and build it locally.

For reference, it saved 5MB (Vite is now at 18MB) when they were removed in Vite https://github.com/vitejs/vite/commit/1c1f82f93bc49ce3a94e23fe99eff377be691b60

authors: aleclarson antfu patak-dev

repo: vitest-dev/vitest


text:
Resource location issue

SURFMirflickr25K256 feature cannot load the resource file as it is not found.
Branch: multi-module

It expects a resources folder to be present at './resources'. The current build process does apparently not copy these resources properly. We will have to add that...

Instead of copying some resource folder, the ideal way is to put them in src/main/resources where they're automatically copied to the jar. This simplifies the build process.

@silvanheller they are located in cineast-core/src/main/resources/ - however, adjusting the CODEBOOK_FOLDER to codebooks/ does not fix the issue.
TL;DR: As @lucaro pointed out, the codebook files shall be copied to an accessible location during build

We did in the past explicitly not copy these kinds of resources into the jar since they are very large which would bloat the jar and slow down the loading of everything and since they are (to a certain degree) user configurable. The code books for example can be generated via cineast, so if someone wants to generate one for their specific use case, they can do so. Same is true for the DNNs.

@sauterl is this still reproducible?

authors: lucaro sauterl silvanheller

repo: vitrivr/cineast


text:
[dev] CLI preview limit is not respected

(dev branch) As a simple example, consider:
This might be similar to #97.
🥕query preview -l 5 cineast.features_visualtextcoembedding
Executing query (took: 192.270266ms):
┌───────────────────────────────────────────┬───────────────────────────────────────────────────────────┐
│ cineast.features_visualtextcoembedding.id │ cineast.features_visualtextcoembedding.feature            │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_13831_11                                │ [-0.029546281, 0.12945361, 0.09901086.., -0.006075851]    │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_13831_12                                │ [0.029192688, 0.0620341, 0.11323794.., -0.06276648]       │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_13831_13                                │ [0.03029386, 0.02563509, 0.114817925.., -0.090105996]     │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_13831_14                                │ [0.016879018, 0.036000475, 0.0952216.., -0.07576223]      │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_13831_15                                │ [0.028322164, 0.037120562, 0.089433864.., -0.076153785]   │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_04349_373                               │ [0.043302238, -0.009606847, -0.056591675.., -0.055982262] │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_16137_83                                │ [-0.029158104, 0.034594886, 0.011026163.., -0.015013492]  │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_00001_1                                 │ [0.061704352, -0.0023821415, -0.043111034.., -0.09961325] │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_04349_374                               │ [0.04956955, 0.002650689, -0.060083672.., -0.03594876]    │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_16137_84                                │ [0.013935343, 0.101374656, -0.108379096.., -0.045034055]  │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_00001_2                                 │ [0.0683381, -0.016747238, -0.08511494.., -0.023090225]    │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_04349_375                               │ [0.07068111, 0.008773927, -0.039488703.., 0.012712836]    │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_16137_85                                │ [0.061524417, 0.071982786, -0.059638932.., -0.013912878]  │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_00001_3                                 │ [0.108355016, -0.042504326, -0.049022645.., -0.030157302] │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_04349_376                               │ [0.07305551, 0.02163916, -0.050543644.., -0.08995472]     │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_16137_86                                │ [-0.0010923533, -0.015819965, -0.04956792.., 0.029583266] │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_00001_4                                 │ [0.15137735, 0.014235466, -0.059754588.., -0.0550076]     │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_04349_377                               │ [-0.006562865, 0.020549528, 0.02029335.., -0.046301298]   │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_16137_87                                │ [0.010479225, 0.036545616, 0.017997168.., -0.046947137]   │
├───────────────────────────────────────────┼───────────────────────────────────────────────────────────┤
│ v_00001_5                                 │ [0.09943178, 0.02357462, -0.030596644.., -0.027111232]    │

Addressed on dev. Please check!

authors: ppanopticon silvanheller

repo: vitrivr/cottontaildb


text:
GitHub Flavoured UI

The Application will look more impactful if the UI elements follow GitHub's Styling.

Agree. Thanks for creating the issue. Would you like to work on this? You can simply run the frontend react application by referring to the instructions mentioned in this readme file.

Agree. Thanks for creating the issue. Would you like to work on this? You can simply run the frontend react application by referring to the instructions mentioned in this readme file.

If this can be achieved just by editing the CSS files then, I'll love to implement it.

yes. you can create and include the scss files or if you want you can also add stylings inline to the component. I'm using MUI components and it provides several ways to style a component.

Is someone working on this? If not, I would love to pick it up..

@cool-pants
Go Ahead for sure!
Currently my college Unit Test are about to begin,
So I won't be able to start until the next Saturday.
In short,
Give it a hit.

Hey Vivek, do you mind if i start working on this?

Hey Vivek, do you mind if i start working on this?

yeah sure. @cool-pants are you working on this? if not I think @Senor-Ducky can start working on this

Hello! I suggest using the already made CSS library made by Github @cool-pants @Senor-Ducky @vivekweb2013
https://github.com/primer/css

Hello! I suggest using the already made CSS library made by Github @cool-pants @Senor-Ducky @vivekweb2013 https://github.com/primer/css

sure thing!

Hey Vivek, do you mind if i start working on this?

yeah sure. @cool-pants are you working on this? if not I think @Senor-Ducky can start working on this

Well i have started the work, and done most of it. @Senor-Ducky sorry for the late reply.

@cool-pants okay please continue.
Hey @Senor-Ducky. Could you please pick issue 49 instead.

authors: Senor-Ducky andrei-io cool-pants omegaui vivekweb2013


text:
Add missing alternate links

another block that should be in the library...

another block that should be in the library...

Created a task for it

authors: johnnyomair nsams raphaelblum

repo: vivid-planet/comet-starter


text:
Opens then closes immediately

Downloaded the latest version with the slash features - however, after trying to open it closes straight after.
Tried to find out why so I ran it in IDLE and this is what it shows:
Traceback (most recent call last):
  File "C:\Users\xxxx\Downloads\ALL MUDAE FILES\xxxxxxxx\MudaeAutoBot.py", line 10, in <module>
    from discum.utils.slash import SlashCommander
ModuleNotFoundError: No module named 'discum.utils.slash'
>>>

Any idea what I could do to fix this? As far as I am aware I have DISCUM installed unless there is a new version?

And it was working before the new push right ?

Hi yes, it was. I managed to get it to stop closing immediately by installing the latest version of DISCUM however, this is what I am getting now when launching the script:
Exception ignored in thread started by: <bound method GatewayServer._response_loop of <discum.gateway.gateway.GatewayServer object at 0x00000217939C23A0>>
Traceback (most recent call last):
  File "C:\Users\xxxx\AppData\Local\Programs\Python\Python39\lib\site-packages\discum-1.4.0-py3.9.egg\discum\gateway\gateway.py", line 292, in _response_loop
    func(resp)
  File "C:\Users\xxxx\Downloads\ALL MUDAE FILES\xxxxxxx\MudaeAutoBot.py", line 707, in on_message
    bot.gateway.request.searchSlashCommands(str(ghids[0]), limit=100, command_ids=[])
IndexError: list index out of range

Very peculiar - is this perhaps a discum issue? Would reverting back to the old release work better?

Just an update, the previous release still works after running that just now - it seems the latest release is what is giving me this error

Hmm maybe a outdated discum then cause I think when I first released slash commands weren't implemented with older version of discum check if there is a new download from discum

The most recent error I got was with the latest version of discum (1.4). I'll try downloading it directly from discum releases to see if it makes any difference because I did see that when I got my first error, I had ver 1.3 which didn't have the slash commands, but in my most recent error it does show I have 1.4 installed.
I'll try a redownload from discum now and update you on whether it's the same issue.
Just to confirm however, is it worth doing python setup.py build before installing it again?
And do you happen to know how to completely uninstall discum?

Did you enter a guild ID or server id that has access to mudae to query the bot

I just tried the latest release now, it seems I made an error by downloading it via the master code on the home page

Since then I just downloaded it from the releases section and it works now.
I am curious however about the slash rolling:
{    "token":"mxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",    "channel_ids":[ 	  8XXXXXXXXXXXXXXXXXXX15    ],    "slash_ids":[ 	  8XXXXXXXXXXXXXXXXXXX15    ],    "slash_guild_ids":[       8XXXXXXXXXXXXXXXXXXX15    ],    "claim_delay":0.5,    "kak_delay":1,    "use_emoji":"<:keqing_love:795077041761288214>",    "roll_this":"mg",    "rolling":"True",    "slash_rolling":"True",    "pkmrolling":"False",
I have the above settings, but it doesn't seem to roll using the slash commands, instead uses the $ prefix - any ideas?

Slash rolling needs guild id which is a server that has mudae to query
Guild id is a server and not a channel id I see that your channel id looks like your guild id
And then the bot itself have to have slash commands enabled to roll with slash commands
And try not to have the same channel in both as then it try's to roll and slash roll

Ah, got it. Thank you so much man, appreciate the help! All sorted :)

Okay cool I'll close the issue :3

authors: Kaizuk-O vivinano

repo: vivinano/MudaeAutoBot


text:
Change bitrate to 2mbps

Change bitrate to 2mbps
Summary:
Test Plan:

Ugh. Apologies. I didn't mean to send a PR :)


text:
ContextMenu is always Open in v2.0.0-alpha.1

Version
1.2.0
Test Case
Steps to reproduce
Load the example provided.
Expected Behavior
By default, context menu should be closed.
It should only open on right click on the trigger, context menu should close once clicked elsewhere.
Actual Behavior
By default, context menu is visible.
Cannot be closed in anyway.
index.txt

This package does not contain any styling by default. So have you added the styles? Also the classnames have changed from v1.
See README for usage and styles.css for example implementation

Closing due to no activity. Feel free to open, if you still face the issue

I must agree that it's weird there is no default css. I understand you give the freedom to use any css but it looks like a bug. It took me a while to realize everything was working properly...

Hah, I accidentally also stumbled upon this exact issue just 2 minutes after @yotamberk. Totally understand the logic @vkbansal , but since there is no live example (e.g. github pages) user who wants to just see it in action doesn't necessarily understands he needs the css.

@yotamberk I've update the README to be more explicit.

but since there is no live example (e.g. github pages)

@eladmoshe https://vkbansal.github.io/react-contextmenu. It is right at the top!

The reason I do not include styles by default is because everyone has their own preference of hiding/showing elements:

Some use display:none or visibility: hidden but others don't, as it causes reflows and repaints.
Some use opacity: 0 and pointer-events: none. But it does not work on IE.

I can't satisfy everyone. So I let them choose what ever they want.

@vkbansal totally missed the link, thanks! I think many might skip it as well since it is just a link. Maybe prefixing the link with something like "See live example:". Totally agree with your approach regarding customization. Sweet project!

authors: eladmoshe gaurav-quasar vkbansal yotamberk

repo: vkbansal/react-contextmenu