text:
Utility to chain signal handlers

It would make more sense to treat signal handlers as a stack.
When you register a signal handler, it gets pushed onto the top of the stack. When you unregister a signal handler, it is popped from the stack.
When a signal is raised, the signal handler at the top of the stack is called. That signal handler can return true or false to indicate whether the signal was handled. If the signal was not handled, it is delegated to the next handler in the stack. At the bottom of the stack is the default signal handler.
This is how I've seen other pograms use signal handlers, and it is how similar mechanisms work elsewhere, eg. https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler
I saw in another issue you had concerns with how this crate would be able to unregister its own signal handler, since it wouldn't know which handler to restore. I think that's not necessary: this handler can just always defer to the previous C handler if there are no handlers registered through this crate.
This also solves the problem with restoring the default handler: there is no need, since the default handler will be automatically called if no handler is present to intercept the signal.

Hello
I'm not sure I understand your motivation or what exactly you want to do here and how it fits into what signal-hook is supposed to be. But I'll try two guesses. If I'm wrong, please explain what you mean, maybe with an example situation or specific use case you're solving and where signal-hook doesn't work for you :-)
Using the stack as an internal backend mechanism
This is already being done, in a form. The previous signal is chained and called after us and we kind of assume whoever registers after us would do the same. This is a mechanism to live in the same program with other libraries that play with signals and not kill each other.
https://github.com/vorner/signal-hook/blob/master/signal-hook-registry/src/lib.rs#L158
https://github.com/vorner/signal-hook/blob/master/signal-hook-registry/src/lib.rs#L234
However, the „return a flag if it was handled“ is not present, for three reasons:

It would have to be a generally accepted and used pattern, which doesn't seem to be the case in the wild.
It is not true that a signal must always be fully handled by one handler and others are not interested in them. One can have an application where the SIGHUP (default action being terminate) should log that the signal was received, reopen log files and reload configuration files (and not terminate). And each action can be done by a different library, not knowing about each other. So how should they know they should return „signal handled“? The last one in the chain should, but as they don't know about each other, they have no way knowing they are the last. It seems safer from this perspective if everyone who registered a handler gets notified.
We do not remove the backend signal handlers. The issue is, we have no reliable and race-free way to know that we are on the top of the stack and manipulating the raw handlers is racy in multithreaded applications (therefore one better just registers everything upfront and then tweak what happens inside).

Furthermore, one can't put the default handler onto a stack or call it because the default handler is not really a function. SIG_DFL is a numeric constant (1, I think) that masks itself as a function pointer. You can have no handler (SIG_IGN), the default one (SIG_DFL) or your own function, but they are exclusive. The best you can do is „emulate“ the default handler by invoking the same thing, depending on the signal number.
Exposing such API to users
I believe such approach would go against the goals of the library, in particular these two:

Signals should be turned into sane-acting local resource, similar to allocating memory or spawning a thread. There should be no top-level oversight from the end application author needed. If a library spawns a thread, this should have no effect on other libraries doing the same. If a library wants to listen to a signal, doing so should not in any way disrupt other libraries or parts of application that do that. By allowing one handler to consume the signal for others and cut them off from the information seems in conflict with it, see the above example with logging/reloading/reopening. The approach „everyone who expressed an interest gets notified“ seems more closer to the idea of the subscriptions being independent. Furthermore, the flag „I've handled it“ approach is much more prone to unwanted breakage due to reordering the registration, and considering I've seen libraries register eg. SIGCHLD lazily on demand, that could blow up. The current approach seems a bit less powerful but also less inclined to break in hard to debug ways.
Users should be able to do common things without using unsafe code. But the content of the actual signal handler must be async-signal-safe, which means no allocations, no locking, and many more „no“-something, and violating that is UB. Therefore, any custom user code that goes in there must be registered with unsafe, to ensure users properly checked that code. The way the library goes about this problem is to provide abstractions that are already checked and postpone the handling of the signal to some later time, when the user picks them up (by reading a flag or waiting on an iterator in a designated thread, for example). But to decide if one shall call more signal handlers, it would need to provide the answer right away inside the signal handler, which would require user code being run as part of the handler. That would, in turn, require each user to use unsafe.

Being able to remove the handlers only in reverse order of their registration seems very limiting, considering the goal is for libraries to be able to register and unregister their interest without any interaction with other libraries doing so. Currently unregistering can be done in arbitrary order.
Furthermore, such a big change seems to be in magnitude of „throw it all out and start from scratch“ and then there would be the question why it should be done inside the same library and not a separate one. In particular, this would be a big breaking change to signal-hook-registry and the idea in that is to provide a common meeting ground that will never have a breaking release.
Why not go back to default signal handler
There are two reasons why signal hook doesn't want to ever go back to the default signal handler (and recommends the user to emulate the behaviour if desired).

As noted above, default handler is all or nothing. To revert to it, one needs a willing cooperation not only of signal-hook enabled libraries, but of anyone who registered a signal handler directly too. We know nothing about them, or how to talk to them and cutting them from the signal notifications they subscribed to seems rude to say the least.
Such behaviour would again be very fragile. Imagine that SIGHUP situation again. Let's say we have the configuration reloading library and the logging library that reopens the logs. But what if the configuration library can read part of the configuration that says „no more reloading, freeze the config“. Then it would unregister its handler. Now, if we reconfigure the logging library to log to a network socket, it would not register its handler either. But then, the act of unregistering the config's handler would either only stop reloading configuration, or additionally restore the default handler to terminate the application and there's no way to know which locally.

(The above talks about rolling back to default ones implicitly under some conditions; I've thought about being able to do it explicitly, pausing all signals in the application for a while and then being able to return them back, but that sounded fragile too, considering there's the option to just emulate them)
Is this library the right place?
I slightly suspect that what you're trying to answer here is „how does an application decide what to do with a signal“. This assumes that it's the application deciding somewhere on the top level (which is traditionally the necessity with signals because of their limitations, but signal-hook tries to challenge that dogma).
Signal-hook, on the other hand, tries to answer „How does multiple independent parts of a program not kill each other when dealing with signals“ (think something like a global memory allocator, instead each part of application playing with the brk syscall) and „How do I safely get the signal out of the signal hander to a place where I can actually do something about it comfortably“.
If I'm right in this guess, I believe the right approach would be not to modify signal-hook, but to add an additional layer, the distribution stack. That one would register into signal-hook somehow (using one of the abstractions or maybe go directly to signal-hook-registry) and let the application add or remove these handlers. Any independent library would still get its copy of the notification, because there's nothing known about that library, or if you could ensure there's nobody else dealing with signals, it would act exactly as you describe.
I'm not sure this belongs inside signal-hook, or as a separate library (I could imagine both, depending on how it turns out, in the latter case it would make sense to link to the library from signal-hook's docs). But if you think this is something worth exploring, I'm open to discussing how it would look like API wise.

It is not true that a signal must always be fully handled by one handler and others are not interested in them. One can have an application where the SIGHUP (default action being terminate) should log that the signal was received, reopen log files and reload configuration files (and not terminate). And each action can be done by a different library, not knowing about each other. So how should they know they should return „signal handled“? The last one in the chain should, but as they don't know about each other, they have no way knowing they are the last. It seems safer from this perspective if everyone who registered a handler gets notified.

Even in this scenario, my proposed behaviour makes more sense: just because a library listens for SIGHUP shouldn't change the behaviour of the application. The library should install a signal handler that does its thing and then always returns false (delegating to the next handler).
If the application wants to avoid terminating in response to SIGHUP, then it should install its own signal handler at the very start which just returns true.

Furthermore, one can't put the default handler onto a stack or call it because the default handler is not really a function. SIG_DFL is a numeric constant (1, I think) that masks itself as a function pointer. You can have no handler (SIG_IGN), the default one (SIG_DFL) or your own function, but they are exclusive. The best you can do is „emulate“ the default handler by invoking the same thing, depending on the signal number.

Yeah you have to just re-raise the signal if the previous signal handler was SIG_DFL.

Currently unregistering can be done in arbitrary order.

You don't have to do this: the library would support unregistering in any order, it's just following the stack model would be more usual.

If I'm right in this guess, I believe the right approach would be not to modify signal-hook, but to add an additional layer, the distribution stack.

Fair enough. The main issue I have with signal-hook is that it changes the default behaviour even when no signal handlers are attached. If I attach a SIGTERM handler via signal-hook and then remove it, the SIGTERM is forever blocked. That's absolutely not what I want.
The stack model naturally solves this because if no handler explicitly intercepts the signal then the default will always be called. When signal-hook is in the same program I can't rely on that, even when using the stack model myself.

Signal-hook, on the other hand, tries to answer „How does multiple independent parts of a program not kill each other when dealing with signals“ (think something like a global memory allocator, instead each part of application playing with the brk syscall) and „How do I safely get the signal out of the signal hander to a place where I can actually do something about it comfortably“.

Fair enough: I think this can work for listening to signals, but suppressing the default behaviour of signals is fundamentally a global behaviour, and cannot be managed independently.
Also: signal-hook will call the previous hook, but only if it's not the default, so replacing the default hook with one that does the same thing changes the behaviour of the program.

I've thought about being able to do it explicitly, pausing all signals in the application for a while and then being able to return them back, but that sounded fragile too, considering there's the option to just emulate them

This would make more sense if you want to stick with the model of "all the handlers get called". Then suppressing the default/previous handler would be a separate call.

If the application wants to avoid terminating in response to SIGHUP, then it should install its own signal handler at the very start which just returns true. The library has no idea whether suppressing SIGHUP termination is the right thing to do for the whole application.

Fair enough. The main issue I have with signal-hook is that it changes the default behaviour even when no signal handlers are attached. If I attach a SIGTERM handler via signal-hook and then remove it, the SIGTERM is forever blocked. That's absolutely not what I want.

You have a point there. The removal of the default is a bit of an exception in how it behaves now. The way I've always looked at the existence of default handlers is they are kind of exception/weird and exist only for applications that don't want to touch signal handling. Once one starts doing something about them, they should be taken over completely. But you're right that the current implicit takeover has its set of quirks.
I still don't like the full stack model, for the reasons I've mentioned, I'd prefer to treat all the hooks equally and the need of the application code to be inside the low-level hook (therefore unsafe for everyone) feels as a show stopper. And there's backwards compatibility to consider.
So let's come up with some way that would allow you to build what you want. I'll throw some ideas here and no, they are not final:
Explicit signal takeover
Currently, the signal is taken over implicitly, on first use. We could add some kind of init_signal call. That would explicitly install signal-hooks signal handler. It would also allow for configuration about how it behaves ‒ if it should call into the previous signal handler, if it should suppress the default handler or emulate it, ... Not sure how exactly the configuration would look like or what it would allow.
The signal_hook_registry::register would get deprecated (can't really change that behaviour, that would be breaking) and a different one would be added. That one would error out if called before initialization, making sure application decides what happens to that specific signal before libraries are allowed to play with it. The signal-hook built on top of it would migrate to the new (errorring) version, that one is allowed to have breaking changes.
Emulation of the default handler
Currently, there are docs, but maybe a function default_handler(c_int) that would call whatever equivalence of the signal might be useful (re-raising the signal doesn't work, it would simply receive the signal again).
The stack
Is there a reason why that manual stack thing couldn't contain the default handler emulation on the bottom of the stack? How much does that differ from what you have in mind?
Current options
Without any changes to signal-hook, I think you could register the conditional shutdown and control if its active by a flag. Not exactly what you want, but something that's already there.

Explicit signal takeover

Yeah, explicit initializing would solve the problem I think. You'd have to make it an error to call it more than once. The stack model is simply a way to assign a sensible behaviour to calling this multiple times, but it's not necessary.

Emulation of the default handler

Yeah I looked into this a fair amount, and it's annoyingly difficult. These are the options I have:

Re-implement what we think the default behaviour is. eg. explicitly terminate the program for SIGTERM, etc.
Reset the signal handler and re-raise, then restore the prior signal handler. Accept that there's a race condition if the same signal is raised on a different thread.
Reset the signal handler and re-raise, then restore the prior signal handler. Prevent the race condition using a spin-lock per signal. (The signal that was raised should be automatically masked on the same thread, so we shouldn't deadlock, but it's kinda sketchy, and you might deadlock if the same 2 signals occur in different orders on two threads?)
Reset the signal handler and re-raise, then restore the prior signal handler. Prevent the race condition using a single spin-lock, and configure out handler to mask out all other signals whilst it is executing.

Is there a reason why that manual stack thing couldn't contain the default handler emulation on the bottom of the stack? How much does that differ from what you have in mind?

No: this would be an implementation detail, completely indistinguishable to the user. The default handler should effectively be the bottom of the stack, so there's no special case to consider of an empty stack.

You'd have to make it an error to call it more than once.

Either that, or make the call idempotent (at least as far as the replacement of the low-level signal handler goes, it would be possible to still change some of the internal settings by further calls). But I think making it an error is simpler API.
Anyway, while thinking about it, I worry about one thing. Making it explicit for something like SIGTERM makes sense, but what about signals that have a default handler that do nothing, in partigular SIGCHLD? I know at least 2 async runtimes now use signal hook behind the scene to handle SIGCHLD for getting notified about asynchronously running processes and that is supposed to „just work“. I think nobody would be happier about having to allow the takeover of SIGCHLD.
So what I'm thinking about, it should still allow for the configuration, but in case of the ones that don't do anything by default, implicit initialization should still stay a possibility.

Yeah I looked into this a fair amount, and it's annoyingly difficult. These are the options I have:

I'm inclined to 1. in here. Looking through documentation, POSIX says what the default handlers should do and there are only like 3 or 4 options. Furthermore, if there's a bug, someone will notice fast and report it.
All the others are prone to having some subtle bugs that happen once in a blue moon, and I don't particularly like spin locks that could happen out of the blue inside any part of the program (though people would do better if they masked the signals inside their realtime threads anyway).

The default handler should effectively be the bottom of the stack, so there's no special case to consider of an empty stack.

I was just checking this is implementable, not if the default handler should or should not be visible to users.
Anyway, I was wondering if this could be created in more generic way. Some way o callback chain stack data structure might be useful for other purposes, not just signals, with interface something like:
enum ContinuationOp<R> { Stop<R>, Continue };
struct DispatchStack<P, R> { .. }

impl DispatchStack<P> {
  fn push(&mut self, cback: Box<FnMut(P) -> R>);
  fn pop(&mut self);
  fn dispatch(&mut self, param: P) -> Option<R>);
}

I'm inclined to 1. in here. Looking through documentation, POSIX says what the default handlers should do and there are only like 3 or 4 options. Furthermore, if there's a bug, someone will notice fast and report it.

AIUI, there are 4 options:

Do nothing
Stop
Terminate
Terminate with crash dump

1 + 3 are easy enough to implement. The others I'm unsure how you'd implement.
This is an extract from my attempt to implement a stack-based signal model:

        unsafe fn delegate(&self, signum: libc::c_int, data: Self::Data) {
            if self.0.sa_sigaction == libc::SIG_DFL {
                // Default handler. We want to re-raise the signal, but doing so is racy,
                // so avoid doing it if the default action is to do nothing anyway. If the
                // default action is to terminate the process, then it doesn't matter if
                // restoring the original handler is racy since we won't get to that part...
                //
                // If the default action is to pause the process, then the race condition may
                // be a problem when the process is resumed. There's not a huge amount we can
                // do about that though...
                match signum {
                    libc::SIGCHLD | libc::SIGCONT | libc::SIGURG | libc::SIGWINCH => {}
                    _ => {
                        let prev = self.install(signum);
                        libc::raise(signum);
                        if prev.install(signum).0.sa_sigaction != self.0.sa_sigaction {
                            // Uh oh... Race condition! Just set our signal handler again.
                            Self::ours().install(signum);
                        }
                    }
                }
            } else if self.0.sa_sigaction != libc::SIG_IGN {
                // Non-default handler, call directly
                if self.0.sa_flags & libc::SA_SIGINFO != 0 {
                    mem::transmute::<_, SigActionPtr>(self.0.sa_sigaction)(signum, data.0, data.1);
                } else {
                    mem::transmute::<_, SigHandlerPtr>(self.0.sa_sigaction)(signum);
                }
            }
        }

For 2, I raise SIGSTOP. That one is one of the unchangeable signals, so it's guaranteed to be at the default.
For 3, calling _exit works (one needs to call the one with underscore, to avoid calling the at-exit hooks from inside the signal handler).
For 4, calling libc::abort should work ‒ that one tries really hard to terminate the program even if SIGABRT is changed (but if the intention is to terminate, it could be reset beforehand anyway).
I think I'll split this issue into the two parts, one for the signal initialization, another for that stack (though I'm still unsure if it should be in here).

I've extracted the emulation and the initialization to #81 and #82 respectively. I'm leaving this open to hold the idea of the chain-stack thing one could feed signals into and get them distributed.

I've extracted the emulation and the initialization to #81 and #82 respectively. I'm leaving this open to hold the idea of the chain-stack thing one could feed signals into and get them distributed.

I created crates signal-stack and grace for chaining signals and portably handling graceful shutdown respectively. The former should work compatibly with signal-hook. The latter exists because I wanted to avoid using signals entirely on windows, and it provides a safe interface.

I created crates signal-stack and grace for chaining signals and portably handling graceful shutdown respectively. The former should work compatibly with signal-hook. The latter exists because I wanted to avoid using signals entirely on windows, and it provides a safe interface.

authors: Diggsey vorner

repo: vorner/signal-hook


text:
Blender display Nvidia smi is not recognized as an internal or external command, an executable program or a batch file.

“nvidia-smi” is not recognized as an internal or external command, an executable program or a batch file.

ZLUDA with Blender 4.1 compatibility version used
zluda.zip

This is not a zluda issue nor blender; it is a ComfyUI-BlenderAI-node issue.

Does it blocks some functionality?
nvidia-smi is used for querying system GPU properties like GPU clock, memory clock, brand of VRAM, etc. nvidia-smi missing should not be a problem

No problem, Zluda works well, only display the error

Ok, I'm closing it then

source: gharchive/issue

authors: gioxyer vosen wfjsw

repo: vosen/ZLUDA

license_type: permissive

license_source: github-api


text:
Wrap some more commands in "if selinux is enabled"

Pull Request (PR) description
Some selinux commands only work when selinux is enabled.  There are a few that were missed in previous updates.
This Pull Request (PR) fixes the following issues

Github isn't displaying the module.pp diff well, it really is just adding an if wrapper.

source: gharchive/pull-request

repo: voxpupuli/puppet-selinux


text:
Structured facts display could be improved

Facter 2.0 introduced structured facts (compared to only key-value pairs in 1.x). In the 2.0.x series of Facter, no structured facts were provided by default. However, as stated in the Facter 2.1.0 announcement, now partitions is the first standard structured fact (hash).
Please add support for this in Puppetboard. By support I mean one should think of a way it can be displayed 'nicely', rather than for example:
partitions  {"vda1"=>{"uuid"=>"af740304-b2c6-440f-877a-5fb15cf86c39", "size"=>"12578816", "filesystem"=>"ext4"}}

Starting with PuppetDB 3.0 Structured facts are available in JSON format and new endpoints fact-paths, fact-contents and factsets are available.
As @daenney said it is a lot of work to implement reliable browsing in PuppetBoard with both string and JSON type fact values. This will be on the backlog but if anybody really needs this support please submit a PR with a link to this issue.

So Puppetboard has a jsonprint template filter that you can use, see templates/metric.html and templates/metric.html.
It doesn't provide for a nice way to browse and click through it but will at least print it as more humanly readable JSON instead of a long string.

We are open to PRs if anyone wants to attempt to implement an API for this. Hopefully it can make it into the 0.2.x series.

As of PuppetDB 4.2.0 a new Inventory endpoint is being provided as well as "dotted query" syntax is made available, also the dot notation is experimental.
It may be possible to make use of these new features in the 0.3.0 series with PuppetDB 5.0.0.

Fixed in v3.3.0 released today. :)

authors: corey-hammerton daenney gdubicki gertvdijk

repo: voxpupuli/puppetboard


text:
react-datesの利用をやめるか検討

ref: https://github.com/react-dates/react-dates/issues/2105

随分と長いこと対応するReactのバージョンを上げきれていないでいる(Enzyme周りが原因という主張)
現在react-datesが提供しているコンポーネントを装飾してingred-uiで提供している
今後も対応がされなさそうであれば利用を取りやめる方向で行きたい

react-dates以外のライブラリを用いる
自前で日付選択コンポーネントを作る

https://github.com/voyagegroup/ingred-ui/issues/975 で対応。

repo: voyagegroup/ingred-ui

license: MIT


text:
Null safety?

Can you please do null safety?

I migrated the package to null safety.

authors: holy-dev vpalcar


text:
Reformat files

Reformatted the Rust, Markdown (and superscripted all the †s in the readme), SVG, and YAML files according to conventions; never touched Passerine files.

As stated in one of the reviews on the PR, most of the actual reformatting was done automatically (with either the official Rust extension for Open VSX or Prettier), and to be quite frank, I have little to no experience with Rust because of my background in Java and Kotlin, hence why all the manual changes are on the Markdown files and not the Rust files; I don't trust that I would be capable of making any Rust changes without fundamentally breaking something. In general, I'll likely undo my commit and then undo the Rust file changes before recommitting and pushing.

No worries, and thank you for going through and correcting the markdown files by hand.

In general, I'll likely undo my commit and then undo the Rust file changes before recommitting and pushing. I'll probably get around to it tomorrow.

Sounds like a plan :)

I did it

Let me take a look, 1 sec.

@Chinay-Domitrix I think there are still some changes to the Rust portion of the project, as well as some markdown changes (i.e. newlines after headings, italics, etc.) that need to be reverted. Can you double checked you've resolved and pushed everything? The number of files changed in this PR should be 4 or 5.
I think some changes may've been reverted when you merged 5a5d5e3 to produce e22283e?

maybe I'll check

Hmm im gonna jank this gimme a sec cause otherwise I have to manually undo everything

Hmm im gonna jank this gimme a sec cause otherwise I have to manually undo everything

Kk. If it's easier, you could probably just open another PR and close this one.

authors: Chinay-Domitrix slightknack

repo: vrtbl/passerine


text:
How to use the gui ?

Love this project, and want to extend it.
But i honestly can not work out how to make the GUI play the music sequence that is loaded.
I watched the video and cant quite see what your pressing to make it work.
https://www.youtube.com/watch?v=fokSSaz3mbs

Sorry, this issue slipped my attention; I'm in summer mode so hobby development is smaller. Try F5-F8 keys or hitting space? Is this what you are after?

Closing this as this is probably not relevant anymore.

repo: vsariola/sointu


text:
bug: vim.tbl_islist is deprecated

Check the following:

[X] I have checked the behavior after setting "vscode-neovim.neovimClean" in VSCode settings.
[X] I have read the vscode-neovim docs.
[X] I have searched existing issues.

Neovim version (nvim -v)
0.10.0
Operating system/version
Windows 11
Describe the bug
After neovim 0.10, vim.tbl_islist is deprecated. With neovim 0.10, everytime open vscode with vscode-neovim, the warning message show up.

Maybe update below vim.tbl_islist to utils.islist refer: https://github.com/nvim-telescope/telescope.nvim/pull/3109

Steps To Reproduce

With neovim 0.10, open vscode with vscode-neovim
waring message shows up vim.tbl_islist is deprecated...

Expected Behavior
No waring message

You're using nvim 0.11.0

authors: Adnios xiyaowong

repo: vscode-neovim/vscode-neovim


text:
bug: "neovim 0.10 required" error, with neovim 0.10 prerelease

Check the following:

[X] I have checked the behavior after setting "vscode-neovim.neovimClean" in VSCode settings.
[X] I have read the vscode-neovim docs.
[X] I have searched existing issues.

Neovim version (nvim -v)
NVIM v0.10.1
Operating system/version
Windows11 > WSL > Ubuntu 24.04 LTS
Describe the bug
I have the vsscode-neovim plugin installed, and everything was fine.  But of late, whenever I launch vscode, I get this alert message indicating

vscode-neovim requires nvim version 0.10.0 or higher. 0.10.0 Install the latest stable version.

I could have ignored this warning.  But if I continue using vscode editor, randomly the vscode gets disconnected and another notification comes up saying "neovim disconnected".  After this, I have to close the vscode editor and reopen it to get the plugin working.   I can;'t predict when this disconnect happens.  It is erratic and happens randomly, like twice or thrice in a day.

I have also checked a similar issue https://github.com/vscode-neovim/vscode-neovim/issues/1684 that talks about nvim being disconnected and tried that option of changing the extensionKind.  This doesn't solve the issue of "neovim 0.10 required".  I am observing whether it solves the disconnection issue or not, because it takes time to observe this random behavior.
Steps To Reproduce
This behavior is observed in WSL / Ubuntu and also in native Ubuntu OS.

Upgrade the existing neovim 0.9 to   0.10.1 on WSL/Ubuntu.
Have the vscode neovim plugin installed.
Launch the vscode editor with any project. Example:  goto a sourcecode root directory and type "code ." from the terminal.
vscode launches and initializes itself and shows this notice.

Expected Behavior
The two alerts should not be appearing.
the exteion should not keep disconnecting.

neovim disconnection happens, even after chanigng the extensionKind

view the vscode-neovim logs to see the exact path (and its version info) to Nvim being used by vscode-neovim

You mean this view..  These logs and messages are empty.

and this...

in the vscode-neovim logs view (not "messages"), click the gear icon and select "debug". then click it again and select "set as default".
then restart and try again. if no logs appear, the extension isn't running.

Here is the output.

I still get the alert saying nvim version .10 or higher required.
the neovim editing works, in spite of the above msg.
The erratic behaviour might surface anytime.

2024-09-11 11:37:21.762 [info] MainController: Starting nvim: /usr/bin/nvim.appimage -N --embed --cmd source /home/rvnath/.vscode-server/extensions/asvetliakov.vscode-neovim-1.18.11/runtime/vscode-neovim.vim --clean
2024-09-11 11:37:22.341 [info] MainController: Nvim info: {
  nvimVersion: {
    minor: 10,
    build: 'g27fb62988',
    api_prerelease: null,
    prerelease: true,
    api_level: 12,
    major: 0,
    api_compatible: 0,
    patch: 0
  },
  logFile: '/home/rvnath/.local/state/nvim/log',
  configDir: '/home/rvnath/.config/nvim'
}
2024-09-11 11:39:29.234 [debug] BufferManager: Visible editor, viewColumn: 1, doc: vscode-userdata:/c%3A/Users/ravindranath.m/AppData/Roaming/Code/User/settings.json
2024-09-11 11:39:29.235 [debug] BufferManager: Setting active editor - viewColumn: 1, winId: 1002
2024-09-11 11:39:29.236 [debug] BufferManager: Cancel visual mode to prevent selection from previous editor to carry over to active editor
2024-09-11 11:39:29.237 [debug] ModeManager: Changing mode to n
2024-09-11 11:39:29.237 [debug] ModeManager: Setting mode context to normal
2024-09-11 11:39:29.347 [debug] BufferManager: window changed, target window id: 1002
2024-09-11 11:39:36.314 [debug] TypingManager: Send for: <C-a>

Your logs show prerelease: true. As mentioned in https://github.com/vscode-neovim/vscode-neovim/issues/2227#issuecomment-2334836590 and https://github.com/vscode-neovim/vscode-neovim/issues/2225#issuecomment-2334832907 , you need to update to an actual v0.10.0 release, not a prerelease (which could be any commit before the final release).
Your logs also show the exact Nvim path that was used (perhaps you configured it in vscode settings): /usr/bin/nvim.appimage.
Either update your settings, or clear the setting so that vscode-neovim will search $PATH for a valid Nvim.

authors: justinmk rv-nath


text:
Better plotting with ImPlot

Hi Robert,
this is not really an issue, since VsgImgui works well. It's plot capabilities are very limited yet. You cannot define axis labels for example. There is a companion project called ImPlot, which can be integrated into ImGui/VSGImgui. Actually I needed gui-charts in project::chrono, so I made a modified version of the VsgImgui library.

I think some users would like this additional feature. What is your opinion?
Best
Rainer

I am not familiar with ImPlot so can't provide any guidance on it until I've learned more.  As I'm deep in a code review of the core VSG in prep for 1.0 I'll need to handle this after the release.
If you have a modified vsgImGui then could you share this so I can review it there.

Here is it:

There is a PR.

authors: rainergericke robertosfield

repo: vsg-dev/vsgImGui


text:
Add Prune jobs to the rewrite

Add the check job logic to the new implementation: https://github.com/vshn/k8up/tree/master/service/prune
The controller is already implemented for that. Now we need to implement an Executor that actually triggers the job.
That one should be quite trivial to implement.
With #114 merged the new implementation lives on the development branch.

I'll take this one 👍

authors: Kidswiss mweibel


text:
Show link to changelog in the docs

Summary

This will display a link in the navigation pointing to GitHub release, but only when the Antora component was built from a tag in the playbook (not master for example), see https://docs.antora.org/antora/2.3/page/intrinsic-attributes/#page-attributes

Checklist

[x] Keep pull requests small so they can be easily reviewed.
[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking,
as they show up in the changelog
[x] Update the documentation.

Cool. Never used that before, let's see how this works when we tagged the release.

Cool. Never used that before, let's see how this works when we tagged the release.

authors: ccremer tobru


text:
ARB (JSON) Handicapped without 'replacing source text'

I checked out the new ARB / JSON when I saw your announcement about this feature. The format and the support in POEdit looks great, except I see that this format doesn't ship with the source text to translate. I guess that is why you also added 'Replacing source text with reference translations' at the same time.
That feature is just in the Pro version though, which effectively means the free version doesn't support ARB at all. I say that because how could one translate an ARB file if one couldn't see the source texts, just the symbols? This problem isn't there with the other formats, like XLIFF, .po files, etc.
What do you think about opening up the 'Replacing source text with reference translations' feature in the free version just for formats like .ARB, where the source text is not included in the file? This way ARB files are at least editable.
The reason I ask is not to avoid sending you $3.33, but because I have to decide on a format for translation files to be opened and used by others, and with this limitation, it seems like the .arb format is essentially unusable.

POEdit

(Why this particular misspelling of the name?)

which effectively means the free version doesn't support ARB at all [...]  it seems like the .arb format is essentially unusable.

I could do without the inflammatory rhetorics, if I'm being honest. The OSS version on which you filed the issue, does open English files. Plus you have other options, e.g. starting from English text or opening multiple windows...
I think it's reasonable to ask for payment for a few conveniences to fund the development. Expecting everything on a silver plate; less so.
Having that said, this is under consideration, but a topic for this OSS tracker, so closing.

I have to decide on a format for translation files

You have many options, including JSON-based variants that store source text, e.g. WebExtension's or XLIFF.

Sorry, I didn't expect that to be controversial. After all, you support showing the source text for every other format (at least that I have tested). I figured it was just an oversight.

After all, you support showing the source text for every other format

Poedit shows the source as present in the file. ARB chooses to use a cryptic ID for the source text and to not include full information in its source-form files. It's absolutely not the case that Poedit is "not showing the source text" - the cryptic ID is the source text.

I figured it was just an oversight.

Revisionist much? Re-read this issue's description.

authors: isaksky vslavik

repo: vslavik/poedit


text:
Introduce a "recording mode" that allows visually authoring tours

Currently, you can authors code tours "manually" by creating the JSON file. However, I plan to allow the user to "start recording", and then navigate across files, clicking on relevant lines, and adding comments visually. That way it's very quick to create new tours for a codebase.

Just checked this in.

repo: vsls-contrib/code-tour


text:
Add BrightFutures by @Thomvis to EventBus section

Project URL

https://github.com/Thomvis/BrightFutures
Description

Add BrightFutures by @Thomvis to EventBus section
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 8 or later
[x] Supports Swift 3
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Error

  :no_entry_sign:
  Found 1 link issue

Link issue by awesome_bot

Line
Status
Link

1005
500
https://pushbots.com/

  Generated by :no_entry_sign: danger

Cool lib! Thanks @nschucky 😃

authors: danger-awesome-ios lfarah nschucky

repo: vsouza/awesome-ios


text:
textlint の導入

resolve #95
package.jsonファイルのlintスクリプトの内容など、基本的に全てv2を参照しましたが、修正点ありましたら教えていただけますと助かります🙇♀

@kazupon
確認ありがとうございましたmm

@Katakuranatsumi
Nuxt 公式ドキュメントのほうにも textlint を導入しようと考えています。

ci: content/ja に対して textlint を導入する · Issue #221 · vuejs-jp/ja.nuxtjs.org

そういう背景もあって質問なのですが、
https://github.com/Katakuranatsumi/ja.vuejs.org/blob/b7757804798a97ec077a3eae476cc5691037050e/package.json#L17
のところで、textlint コマンドではなく JavaScript のコマンドを書いている意図を知りたく。つまり、textlint コマンドでは解決できない問題があったのかが知りたいと思っています。
お手数ですが、よろしくお願いします 👍

package.jsonファイルのlintスクリプトの内容など、基本的に全てv2を参照しました

あっ、あっ！ごめんなさい！書いてありましたね。v2 のものから移植したのですね。把握しました！ 🙇

@inouetakuya
はい、こちらはv2から移植したものになりますmm
よろしくお願い致します🙇♀

承知しました！ありがとうございます！ ☺

authors: Katakuranatsumi inouetakuya


text:
dev tools crashing after hot realoding

Vue devtools version
6.6.4
Link to minimal reproduction
no
Steps to reproduce & screenshots
I've been noticing that in all projects I work with vue, whether it's simple or complex when hot reloading the devtools is crashing and I need to click on the X and open it again. This problem its happening on Edge browser
So if I'm using vue store or pinia they disappear

What is expected?
Not crash
What is actually happening?
Exteions its crasing and i need to close and re open again the extesion after hot reload
System Info
System:
    OS: Windows 11 10.0.22631
    CPU: (12) x64 AMD Ryzen 5 3600 6-Core Processor
    Memory: 6.56 GB / 15.92 GB
  Binaries:
    Node: 20.18.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.22 - C:\Program Files\nodejs\yarn.CMD
    npm: 10.8.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (130.0.2849.46)
    Internet Explorer: 11.0.22621.3527

Any additional comments?
No response

Hi I have been experiencing this issue for several weeks now and it is making work with the devtools particularly frustrating and almost unusable. It's a pity, because it was working pretty well before.
For information, this problem is also happening in Chrome.

Same here with 7.6.3
This is happening when using pinia stores only. Chrome.

authors: Avaru PwtKCL lipecss


text:
dts emit file(.vue.d.ts) that has ts prompt error

version
"vue-tsc": "^2.0.16"
question

The output dts file cannot use InstanceType normally, as follows:

I looked at the dts files generated by earlier versions of vue-tsc and they are different, as follows:

The output dts file can use InstanceType normally, as follows:

version
"vue-tsc": "^2.0.16"
question
 The output dts file cannot use InstanceType normally, as follows:
I looked at the dts files generated by earlier versions of vue-tsc and they are different, as follows:  The output dts file can use InstanceType normally, as follows:

I found that this problem only occurs when automatically importing, globalThis is a global namespace, as long as automatic import is used in the project to generate auto-imports.d.ts, there should be no problem. Please close this issue.

repo: vuejs/language-tools


text:
Add option to bundle as a consumable component library instead of web app

What problem does this feature solve?
vue-cli currently assumes any usage is for a web application, but it does not allow for bundling a library of individual components that can be consumed by other applications.
What does the proposed API look like?
vue create {app}
What is your intended project type?

Web Application
Component Library
Plugin
etc.

vue-cli currently assumes any usage is for a web application

No it does not. Please read this chapter of the documentation:
https://github.com/vuejs/vue-cli/blob/dev/docs/build-targets.md

That's exactly what I needed. Sorry about that.

Looks like docs directory structure changed, here's the working link to build-targets.md: https://github.com/vuejs/vue-cli/blob/dev/docs/guide/build-targets.md

authors: LinusBorg Rleahy22 bivainis

repo: vuejs/vue-cli


text:
Warning Message on Installation

Version
3.0.0-rc.10
Node and OS info
Node 8.11.3 / Npm 5.6.0 / Mac OSX High Sierra 10.13.6
Steps to reproduce
Just install the package:
sudo npm install -g @vue/cli
What is expected?
Installation without any warning messages.
What is actually happening?
The warning message below is shown.
npm WARN apollo-client@2.3.7 requires a peer of graphql@^0.11.0 || ^14.0.0 but none is installed. You must install peer dependencies yourself.

Some packages specify their peer deps but we need to use them as a nested dependency when we know the peer dep is available higher in the tree. You can safely ignore it.

Nvm, this seems to be coming from https://github.com/Akryum/vue-cli-plugin-apollo
/cc @Akryum

https://github.com/apollographql/apollo-client/issues/3737

authors: Akryum leonardo-sj yyx990803


text:
vue-cli3中的vue.config.js文件怎么配置，使得chunk-vendors被分离，以给不同的页面引用？

Version
3.1.0
Reproduction link
Node and OS info
v8.11.3
Steps to reproduce
1、vue-cli3中，在vue.config.js文件中配置了pages参数进行多页面开发，pages参数中的chunks采用默认配置。
2、进行npm run build 后，打包后，dist文件夹中有两个入口 index.html 和mobile.html . 而这两个html都引用了同一个chunk-vendors。
3、由于index页面是全局引用element-ui的，所以导致chunk-vendors文件特别大。但是mobile页面是不需要引入element-ui的。
4、请问vue.config.js怎么配置才能实现把vue，vue-router等公用的打包成chunk-vendors，而各个页面再打包自身所需要的chunks，就如打包成三个chunks： chunk-vendors.js (index.html 和mobile.html 都引用） ，chunk-index.js(index.html引用）, chunk-mobile.js（mobile.html引用）？
What is expected?
减少mobile.html加载的大小,chunk-vendors被分离
What is actually happening?
参看其他步骤

vue.config.js 配置的多页面是这样的：
pages: {
mobile: {
entry: 'src/pages/mobile/main.js',
template: 'public/mobile.html',
filename: 'mobile.html'
},
index: {
entry: 'src/pages/index/main.js',
template: 'public/index.html',
filename: 'index.html'
}
}

同上，被坑了一把，试了很多方法都不行，vendors都不生成了

同上，搞得样式都错乱了。。。样式都加在一起了

请问题主解决了这个问题吗

webpack 会默认给commonChunk打进chunk-vendors。所以需要对webpack的配置进行delete
chainWebpack: config => {
  config.optimization.delete('splitChunks')
}

@yinsang
这样子就没了vendor了怎么办？
  File                           Size                  Gzipped

  dist\js\front.531f6826.js      250.67 KiB            86.37 KiB
  dist\js\admin.e5621a73.js      199.60 KiB            67.72 KiB

@yinsang
这样子就没了vendor了怎么办？
  File                           Size                  Gzipped

  dist\js\front.531f6826.js      250.67 KiB            86.37 KiB
  dist\js\admin.e5621a73.js      199.60 KiB            67.72 KiB

首先要想明白你需要什么，若是vue.min.js之类的可以用script src引入
若是一定要生成vendor，可以设置webpack 的chunk个数配置何时打包。
https://webpack.js.org/plugins/commons-chunk-plugin/#passing-the-minchunks-property-a-function

@yinsang 可不可以做到front有一个verdor，admin也有一个verdor，它们专门存放node_modules的包，然后这两个verdor中的公共部分放在common-verdor中？

@yinsang 可不可以做到front有一个verdor，admin也有一个verdor，它们专门存放node_modules的包，然后这两个verdor中的公共部分放在common-verdor中？

https://webpack.js.org/plugins/split-chunks-plugin/#split-chunks-example-3
这个可能帮到你。主要还是制定好规则分组。

https://github.com/vuejs/vue-cli/issues/2381  此处是你需要解决的方案

@yinsang 可不可以做到front有一个verdor，admin也有一个verdor，它们专门存放node_modules的包，然后这两个verdor中的公共部分放在common-verdor中？

https://webpack.js.org/plugins/split-chunks-plugin/#split-chunks-example-3
这个可能帮到你。主要还是制定好规则分组。

好，有用，研究下，Thanks

我最近也有类似的需求，研究了下实现了。写了篇文章。请见：
https://juejin.cn/post/6900934461660069902

authors: 897049470 ChenSee DemoHu fengxinming neilzhang618 wangyongjie weituotian yinsang


text:
Cypress fails test:e2e script with --headless option

Version
4.0.5
Reproduction link
https://github.com/kepikoi/vue-cli-repro
Environment info
 System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
  Binaries:
    Node: 10.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.12.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: 44.18362.387.0
  npmGlobalPackages:
    @vue/cli: Not Found

Steps to reproduce
npm run test:e2e -- --headless
What is expected?
base vue-cli setup executes the e2e test successfully in headless mode to be incorporated into a ci/cd pipeline
What is actually happening?
it fails with ERROR  Error: Command failed: C:\www\testing\vue-cli\superbase\node_modules\cypress\bin\cypress run --config baseUrl=http://localhost:8080/
> superbase@0.1.0 test:e2e C:\www\testing\vue-cli\superbase
> vue-cli-service test:e2e "--headless"

 INFO  Starting e2e tests...
 INFO  Starting development server...

 DONE  Compiled successfully in 13022ms                                                                                3:57:58 PM

  App running at:
  - Local:   http://localhost:8080/
  - Network: http://192.168.178.25:8080/

  App is served in production mode.
  Note this is for preview or E2E testing only.

 ERROR  Error: Command failed: C:\www\testing\vue-cli\superbase\node_modules\cypress\bin\cypress run --config baseUrl=http://localhost:8080/
Error: Command failed: C:\www\testing\vue-cli\superbase\node_modules\cypress\bin\cypress run --config baseUrl=http://localhost:8080/
    at makeError (C:\www\testing\vue-cli\superbase\node_modules\execa\index.js:174:9)
    at Promise.all.then.arr (C:\www\testing\vue-cli\superbase\node_modules\execa\index.js:278:16)
    at process._tickCallback (internal/process/next_tick.js:68:7)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! superbase@0.1.0 test:e2e: `vue-cli-service test:e2e "--headless"`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the superbase@0.1.0 test:e2e script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\autod\AppData\Roaming\npm-cache\_logs\2019-11-05T14_58_01_691Z-debug.log

vue-cli setup was done with following options:
Vue CLI v4.0.5
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Linter, E2E
? Pick a linter / formatter config: Basic
? Pick additional lint features: (Press <space> to select, <a> to toggle all, <i> to invert selection)Lint on save
? Pick a E2E testing solution: Cypress
? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.? In dedicated config files
? Save this as a preset for future projects? (y/N)

Can't reproduce on my machine… Perhaps a cypress bug? Any more error logs?

@sodatea @kepikoi I can reproduce on my machine, though for me failure happens regardless of whether or not I use headless.
Our project suddenly stopped working, running the test:e2e command would do a build but not launch Cypress or attempt any tests.  The end of the command run in the Vue UI looks like this:

[webpack.Progress] 100%
No type errors found
Version: typescript 3.6.4
Time: 17949ms
App running at:

Local:   https://localhost:8080/client/
Network: https://localhost:8080/client/

Note that the development build is not optimized.
To create a production build, run yarn build.
Total task duration: 56.8s

I get the same result when I cloned and ran your sample project.  Looks like Cypress 3.6.0 came out recently but I haven't been able to narrow down if that is the cause of this issue or not. Here is my environment info:
System:
OS: Windows 10
CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
Binaries:
Node: 12.7.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.19.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 6.10.0 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: 44.18362.387.0
npmPackages:
@fortawesome/vue-fontawesome: 0.1.8 => 0.1.8
@syncfusion/ej2-vue-base: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-buttons: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-calendars: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-diagrams: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-dropdowns: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-grids: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-inputs: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-lists: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-navigations: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-notifications: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-pdfviewer: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-popups: 17.3.26 => 17.3.26
@syncfusion/ej2-vue-splitbuttons: 17.3.26 => 17.3.26
@vue/babel-helper-vue-jsx-merge-props:  1.0.0
@vue/babel-plugin-transform-vue-jsx:  1.0.0
@vue/babel-preset-app:  4.0.5
@vue/babel-preset-jsx:  1.1.1
@vue/babel-sugar-functional-vue:  1.0.0
@vue/babel-sugar-inject-h:  1.0.0
@vue/babel-sugar-v-model:  1.1.1
@vue/babel-sugar-v-on:  1.1.0
@vue/cli-overlay:  4.0.5
@vue/cli-plugin-babel: ^4.0.5 => 4.0.5
@vue/cli-plugin-e2e-cypress: ^4.0.5 => 4.0.5
@vue/cli-plugin-eslint: ^4.0.5 => 4.0.5
@vue/cli-plugin-router: 4.0.5 => 4.0.5
@vue/cli-plugin-typescript: ^4.0.5 => 4.0.5
@vue/cli-plugin-unit-mocha: ^4.0.5 => 4.0.5
@vue/cli-plugin-vuex: 4.0.5 => 4.0.5
@vue/cli-service: ^4.0.5 => 4.0.5
@vue/cli-shared-utils:  4.0.5
@vue/component-compiler-utils:  3.0.2
@vue/eslint-config-prettier: 5.0.0 => 5.0.0
@vue/eslint-config-typescript: 4.0.0 => 4.0.0
@vue/preload-webpack-plugin:  1.1.1
@vue/test-utils: 1.0.0-beta.29 => 1.0.0-beta.29
@vue/web-component-wrapper:  1.2.0
eslint-plugin-vue: 5.2.3 => 5.2.3
typescript: 3.6.4 => 3.6.4 (3.7.2)
vue: 2.6.10 => 2.6.10
vue-cli-webpack:  1.0.0
vue-eslint-parser:  2.0.3 (5.0.0)
vue-hot-reload-api:  2.3.4
vue-loader:  15.7.2
vue-router: 3.1.3 => 3.1.3
vue-style-loader:  4.1.2
vue-template-compiler: 2.6.10 => 2.6.10
vue-template-es2015-compiler:  1.9.1
vuex: 3.1.1 => 3.1.1
vuex-module-decorators: 0.11.0 => 0.11.0
npmGlobalPackages:
@vue/cli: Not Found

@danjohnso I'm actually having the same issue when running without --headless: no tests are executed in the run. That is  why I assumed I need to use headless in the first place.
@sodatea's I tried to reproduce the issue on a fresh Ubuntu 18 VM, but npm run test:e2e threw Install Xvfb and run Cypress again. at me which apparently was solved in https://github.com/cypress-io/cypress/issues/5110
atlas@testvm:~/vue-cli-repro-master$ npm install

> yorkie@2.0.0 install /home/atlas/vue-cli-repro-master/node_modules/yorkie
> node bin/install.js

setting up Git hooks
can't find .git directory, skipping Git hooks installation

> core-js@3.3.6 postinstall /home/atlas/vue-cli-repro-master/node_modules/core-js
> node postinstall || echo "ignore"

Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!

The project needs your help! Please consider supporting of core-js on Open Collective or Patreon:
> https://opencollective.com/core-js
> https://www.patreon.com/zloirock

Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -)

> core-js-pure@3.3.6 postinstall /home/atlas/vue-cli-repro-master/node_modules/core-js-pure
> node postinstall || echo "ignore"

> cypress@3.6.0 postinstall /home/atlas/vue-cli-repro-master/node_modules/cypress
> node index.js --exec install

Installing Cypress (version: 3.6.0)

 ✔  Downloaded Cypress
 ✔  Unzipped Cypress
 ✔  Finished Installation /home/atlas/.cache/Cypress/3.6.0

You can now open Cypress by running: node_modules/.bin/cypress open

https://on.cypress.io/installing-cypress

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

added 1298 packages from 886 contributors and audited 24906 packages in 107.475s
found 0 vulnerabilities

atlas@testvm:~/vue-cli-repro-master$ npm run test:e2e

> superbase@0.1.0 test:e2e /home/atlas/vue-cli-repro-master
> vue-cli-service test:e2e

 INFO  Starting e2e tests...
 INFO  Starting development server...

 DONE  Compiled successfully in 7182ms                                                                                9:09:36 AM

  App running at:
  - Local:   http://localhost:8080/
  - Network: http://192.168.1.6:8080/

  App is served in production mode.
  Note this is for preview or E2E testing only.

It looks like this is your first time using Cypress: 3.6.0

 ✖  Verifying Cypress can run /home/atlas/.cache/Cypress/3.6.0/Cypress
   → Cypress Version: 3.6.0
Your system is missing the dependency: Xvfb

Install Xvfb and run Cypress again.

Read our documentation on dependencies for more information:

https://on.cypress.io/required-dependencies

If you are using Docker, we provide containers with all required dependencies installed.

----------

Error: spawn Xvfb ENOENT

----------

Platform: linux (Ubuntu Linux - 18.04)
Cypress Version: 3.6.0
 ERROR  Error: Command failed: /home/atlas/vue-cli-repro-master/node_modules/cypress/bin/cypress open --config baseUrl=http://localhost:8080/
Error: Command failed: /home/atlas/vue-cli-repro-master/node_modules/cypress/bin/cypress open --config baseUrl=http://localhost:8080/
    at makeError (/home/atlas/vue-cli-repro-master/node_modules/execa/index.js:174:9)
    at /home/atlas/vue-cli-repro-master/node_modules/execa/index.js:278:16
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! superbase@0.1.0 test:e2e: `vue-cli-service test:e2e`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the superbase@0.1.0 test:e2e script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/atlas/.npm/_logs/2019-11-07T09_09_37_483Z-debug.log

I have the exact same scenario - error on headless and no tests run on regular one. I suppose it's OS oriented as colleagues successfully running tests on UNIX.

See https://github.com/cypress-io/cypress/issues/5466

Is there a way to lock the cypress version being used within the CLI
plugin?  I tried installing and older version but it keeps trying to launch
the latest version instead, must need a config somewhere?
On Thu, Nov 7, 2019, 8:14 AM Haoqun Jiang notifications@github.com wrote:

See cypress-io/cypress#5466
https://github.com/cypress-io/cypress/issues/5466
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue-cli/issues/4799?email_source=notifications&email_token=AAGQIA6IQ5UG337AGCAAV3TQSQPFRA5CNFSM4JJD447KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMRB5I#issuecomment-551096565,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGQIA4RFPWWB4CWM45ASNDQSQPFRANCNFSM4JJD447A
.

Add this field to package.json:
"resolutions": {
  "cypress": "3.4.1"
}

If using yarn, just run yarn again.
If using npm:
rm -r node_modules
npx npm-force-resolutions
npm install

Works @sodatea only till node 12.11.0 version, the default LTS node throw ENOTCONN on this 3.4.1
https://github.com/cypress-io/cypress/issues/5241

I have the same issue @fourpixels on Windows 10 with node 10 with new project created with vue-cli.  Error on headless and no tests run on regular one.

Manually running dev server via yarn serve and then manually run cypress via npx cypress open or npx cypress run works.

Fixed with cypress 3.8.0 released today

authors: danjohnso fourpixels kepikoi layanto marceloavf sodatea


text:
Spelling mistake when creating new project

Version
4.5.13
Reproduction link
NA
Environment info
Mac

Steps to reproduce
npm create vue-app
What is expected?
The second prompt must be How would your describe your superb project
What is actually happening?
"How would your descripe your superb project" (please note the spelling of DESCRIBE)

Sounds like you're in the wrong place, that code is nowhere in this repo, and using npm create/init is not part of the installation instructions. The vue-app package looks to be an old, dead package. Please close this issue.


text:
打包后，父组件隐式传递prop，子组件无法正常获取

Version
5.0.0-beta.6
Reproduction link
github.com
Environment info
  System:
    OS: Windows 10 10.0.19042
    CPU: (4) x64 Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz
  Binaries:
    Node: 16.13.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.17 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 95.0.4638.69
    Edge: Spartan (44.19041.423.0), Chromium (95.0.1020.40)
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.2.1
    @vue/babel-helper-vue-transform-on:  1.0.2
    @vue/babel-plugin-jsx:  1.1.1
    @vue/babel-plugin-transform-vue-jsx:  1.2.1
    @vue/babel-preset-app:  5.0.0-beta.6
    @vue/babel-preset-jsx:  1.2.4
    @vue/babel-sugar-composition-api-inject-h:  1.2.1
    @vue/babel-sugar-composition-api-render-instance:  1.2.4
    @vue/babel-sugar-functional-vue:  1.2.2
    @vue/babel-sugar-inject-h:  1.2.2
    @vue/babel-sugar-v-model:  1.2.3
    @vue/babel-sugar-v-on:  1.2.3
    @vue/cli-overlay:  5.0.0-beta.6
    @vue/cli-plugin-babel: ~5.0.0-beta.6 => 5.0.0-beta.6
    @vue/cli-plugin-eslint: ~5.0.0-beta.6 => 5.0.0-beta.6
    @vue/cli-plugin-router: ~5.0.0-beta.6 => 5.0.0-beta.6
    @vue/cli-plugin-typescript: ~5.0.0-beta.6 => 5.0.0-beta.6
    @vue/cli-plugin-vuex: ~5.0.0-beta.6 => 5.0.0-beta.6
    @vue/cli-service: ~5.0.0-beta.6 => 5.0.0-beta.6
    @vue/cli-shared-utils:  5.0.0-beta.6
    @vue/compiler-core:  3.2.21
    @vue/compiler-dom:  3.2.21
    @vue/compiler-sfc: ^3.2.21 => 3.2.21
    @vue/compiler-ssr:  3.2.21
    @vue/component-compiler-utils:  3.2.2
    @vue/devtools-api:  6.0.0-beta.19
    @vue/eslint-config-standard: ^6.1.0 => 6.1.0
    @vue/eslint-config-typescript: ^7.0.0 => 7.0.0
    @vue/reactivity:  3.2.21
    @vue/ref-transform:  3.2.21
    @vue/runtime-core:  3.2.21
    @vue/runtime-dom:  3.2.21
    @vue/server-renderer:  3.2.21
    @vue/shared:  3.2.21
    @vue/web-component-wrapper:  1.3.0
    eslint-plugin-vue: ^7.2.0 => 7.20.0
    typescript: ~4.1.5 => 4.1.6
    vue: ^3.2.21 => 3.2.21
    vue-cli-plugin-quasar: ^4.0.3 => 4.0.3
    vue-demi:  undefined (0.12.0)
    vue-eslint-parser:  7.11.0
    vue-hot-reload-api:  2.3.4
    vue-loader:  16.8.1 (15.9.8)
    vue-router: ^4.0.3 => 4.0.12
    vue-style-loader:  4.1.3
    vue-template-es2015-compiler:  1.9.1
  npmGlobalPackages:
    @vue/cli: Not Found

Steps to reproduce

npm install
npm run build
用一个本地服务器打开dist文件夹下的index.html

What is expected?
页面渲染的文本应该是msg: msg true
What is actually happening?
msg: msg false

当我的子组件接收一个类型为Boolean的msg props的时候，我在父组件传入msg，正常情况下，子组件获取到msg的值应该是true。这在开发环境下是正确的。当我打包后msg的值是一个空字符串。
在提出这个问题之前，我尝试使用vue-cli创建了一个没有集成typescript的项目，它的表现是正常的。

刚刚测试，如果使用以下写法，打包后也是正常的：

<template>

msg: {{ msg ? 'msg true' : 'msg false' }}

</template>

综合各种情况，目前发现只有用 script setip 语法糖配合 typescript 会出现问题

I'm seeing the same issue.
Same context (I think):

authors: ShaneLee-9 bodograumann sodatea


text:
fix(apiWatch): deep watch should support symbols, performance tweaks

Increased perf of traverse using for (let i...) {} instead of for...in/for...of. Fixed traverse so it will track symbols and add a test case for symbol.

I just stumbled upon this thread randomly and I need to say that I would stay away from microoptimizations like this because they have very noisy and unpredictable results. Since this is not the first time I see things like this here, I have a few things to note:

Browsers have multiple ways to run the same code and the performance of that code literally depends on everything else even if it seems completely irrelevant. From the size of the source code to heat of your CPU.
Browsers optimize the code on the fly based on how it's used, so if you just run it million times in a row, it will probably optimize it a lot which biases the results towards optimized code.
The problem is - most code is NOT optimized, because doing so is slow and browsers usually prioritize running the code sooner, so they will first interpret it and only optimize it when it is run multiple times. If you want to optimize something, you can't rely on browser optimizing it.
Browsers constantly change how this all works in order to improv. They try to balance many tradeoffs. This means that your benchmarks may already be outdated and will almost certainly be outdated in the future
On top of that, many bundlers actually change that code significantly during bundling. For example, in lot of common configs, Babel just replaces the spread operator with something equivalent which works in more browsers but in many cases it's slower.

This all combined means, that if you want to reliably optimize something in JS, you can only make very few assumptions and only do things that are reliably better.

In most cases, this means just simply doing less work - iterating over less things, process less data etc. Things that the browser cannot figure out on its own because it doesn't understand the intent behind your code
Using JS features that are likely to be optimized already - it has been highlighted by browser developers that using things like Array.forEach is good, because these are built into the engine and they are already optimized upfront. And even if they are not optimized at the moment, they will likely be better optmized in the future.
Avoiding patterns that have "Slow semantics" as I call it. Those are things with semantic meaning that already implies doing more work and browsers need to optimize it to make it fast.

Last point is especially a problem with this PR - for example, instead of iterating over Map with builtin .forEach, it first allocates new array, spread all elements from the Map into it and iterate on that - iterating 2 times instead of 1. That is simply just more work to do SEMANTICALLY.
Now it's improtant to note - that might actually be faster at the moment. It is possible that you hit some weird edge case that browsers didn't cover. But because it is semantically more work, you can't rely that this will be the case in the future. Browsers may catch up in the next release and optimize the builtin better.
Manual iteration can also be a bit sneaky. Even though it is faster than functional iteration in lower level languages, in JavaScript it gives the developer too much freedom, so the engine first need to "figure out" that it actutally is manual iteration. If you ask for an element on an index with thing[i], engine needs to typecheck the  thing and check that index doesn't go out of bounds. It does this check by default, but it will optimize it out when it can infer this from the loop control. It needs to do some work to figure that out, though, because JavaScript allows the loop control to be almost any code.
If you use .forEach in modern browsers,  you can assume that browser already has version of that function without additional type&bounds checks, because it has loop code under control and doesn't need to figure it out from your code. The same thing applies to for .. of  and for .. in. These constructs are all more restricted than traditional index-based loops, which gives the browsers more opportunities for optimization. Again - this can be slower at the moment, but has more potential to be faster in the future. This applies especially for interpreting the code, which is done by default on page load and doesn't involve almost any optimization.
That's why optimizations like this that just "does the same thing but in a slighly different syntax" are usually not worth it.
Anyway, this ended up being much longer than I first expected, but I hope it gives some useful information to consider 😉 I don't mean this to be overly negative, it's great that to work on performance. I just wanted to clarify some concerns, because I myself lost a lot of time optimizing JS code and it is often very counter intuitive and you can't just make straightforward conclusions.

repo: vuejs/vue-next


text:
ie9下用history：true  去掉锚点时，并不生效

Vue.js & vue-router.js version
1.0.16, 0.7.11
Reproduction Link

Steps to reproduce
What is Expected?
What is actually happening?

IE9 本来就不支持 history API.......

@yyx990803  尤大，IE9不支持history不是自动变为hash模式吗？我用的history在IE9下，变为hash模式的时候，就是错误的，但是直接用hash就没问题，是什么原因呢？
例如：history模式下：https://e.qianfan578.com/wxm/toLogin这个网址，在IE9下就自动变为https://e.qianfan578.com/#/wxm/toLogin（结果就访问失败了）
但是hash模式下：就会变成https://e.qianfan578.com/wxm/toLogin/#/wxm/toLogin（能访问成功）

authors: Say-Hello shinlyli yyx990803

repo: vuejs/vue-router

license: mit

license_source: bigquery


text:
TypeError: Cannot read properties of undefined (reading 'devtoolsRawSetupState')

Subject of the issue
Beginning with Vue 3.2.25 and the latest version of vue-test-utils I started running into this error on some calls to wrapper.findComponent({ref})  . The problem isn't observed with Vue 3.2.24.
    TypeError: Cannot read properties of undefined (reading 'devtoolsRawSetupState')
      at new VueWrapper (node_modules/@vue/test-utils/dist/vue-test-utils.cjs.js:7611:22)
      at Object.<anonymous> (node_modules/@vue/test-utils/dist/vue-test-utils.cjs.js:7729:79)
      at createVueWrapper (node_modules/@vue/test-utils/dist/vue-test-utils.cjs.js:1721:45)
      at VueWrapper.findComponent (node_modules/@vue/test-utils/dist/vue-test-utils.cjs.js:7311:24)

Steps to reproduce
I don't have an example test case yet. This happens in a larger project. I will need to narrow down the cause first.
Expected behaviour
findComponent should not throw the error
Actual behaviour
findComponent sometimes throws an error.
Possible Solution
Downgrade to Vue 3.2.24

I'm going to look into seeing if it's related to v-for. There was some work around this in 3.2.25

Incorrectly reported to here. This

repo: vuejs/vue-test-utils


text:
vue的tags组件router-link标签跳转已打开页面不重新加载数据,有什么好方法吗？

What problem does this feature solve?
需要让页面不进行重新加载
What does the proposed API look like?

                {{item.title}}

                标签选项

关闭其他
关闭所有

Hi, thanks for your interest but Github issues are for bug reports and feature requests only. You can ask questions on the forum, the Discord server or StackOverflow.

set router parms ，if true update component key value

authors: posva smilingClown xu-yi-hang

repo: vuejs/vue


text:
Required inputs in child components are highlighted as invalid on render in Firefox.

Version
2.5.13
Reproduction link
https://jsfiddle.net/50wL7mdz/85928/
Steps to reproduce
No additional steps required. Opening the JSFiddle in Firefox should automatically cause the issue to display.
What is expected?
Required inputs that are rendered in a child component without a valid default value should display normally.
What is actually happening?
Unselected required inputs are being highlighted as though a submit attempt was made despite no user action being taken.

It looks like Firefox highlights inputs as soon as you touch them using js (input.value = '')
I imagine we could add a condition but I'm not sure if this is just a Firefox bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1399046)

I just ran into this issue too. For what its worth, Angular implemented the additional condition check @posva mentioned in order to work-around it. Here's their commit.

Temporary workaround is to dynamically build object for checked property. It wouldn't contain checked key on first render of the component, but it would have it after user interacted with inout. We can pass this object to v-bind directive.
For example:
<template>
<input type="checkbox"
  required
  @change="!this.checked"
  v-bind="getCheckedState()">
</template>

<script>
export default {
  data() {
    return {
      checked: null
    }
  },
  methods: {
    getCheckedState () {
      if (this.checked !== null) {
        return { checked: this.checked }
      }

      return {}
    }
  }
}
</script>

authors: EdToro74 Walkeryr bryonf posva


text:
sned it

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[ ] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[ ] It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[ ] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

Do tests on your own repo, thank you


text:
[Bug report] Missing sidebar menu items on  beta.52 - beta.62

Description
I've noticed a strange issue when upgrading from v2.0.0-beta.51 to v2.0.0-beta.62, where some of the menu items in the sidebar are missing.
This is what it should look like (In v2.0.0-beta.51): :heavy_check_mark:

And this is how it looks in v2.0.0-beta.62: :negative_squared_cross_mark:

I can't see anything wrong with the config or any other settings, and it doesn't appear to be a sidebar depth issue, it just seems to randomly be missing items at all levels.
Here is the config file: https://github.com/dice-roller/documentation/blob/main/docs/.vuepress/config.js
If I revert the version back to v2.0.0-beta.51, it shows all of the items as expected again.
I've tested at several different versions, and the issue seems to have been introduced at v2.0.0-beta.52.
You can re-produce it by using the following repo, and just changing the version of vuepress and the plugins to v2.0.0-beta.62.
Do you have any idea what might be wrong?
Reproduction
https://github.com/GreenImp/vuepress-dice-roller-test
Used Package Manager
npm
System Info
System:
    OS: Linux 5.19 Ubuntu 22.04.2 LTS 22.04.2 LTS (Jammy Jellyfish)
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i9-12900H
    Memory: 17.65 GB / 31.08 GB
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 18.4.0 - ~/.nvm/versions/node/v18.4.0/bin/node
    Yarn: Not Found
    npm: 8.12.1 - ~/.nvm/versions/node/v18.4.0/bin/npm
  Utilities:
    Git: 2.34.1 - /bin/git
  Browsers:
    Chrome: Not Found
    Firefox: 113.0
  npmPackages:
    @vuepress/bundler-vite:  2.0.0-beta.52
    @vuepress/bundler-webpack: Not Found
    @vuepress/cli:  2.0.0-beta.52
    @vuepress/client:  2.0.0-beta.51 (2.0.0-beta.52)
    @vuepress/core:  2.0.0-beta.51 (2.0.0-beta.52)
    @vuepress/markdown:  2.0.0-beta.51 (2.0.0-beta.52)
    @vuepress/plugin-active-header-links:  2.0.0-beta.52
    @vuepress/plugin-back-to-top: 2.0.0-beta.51 => 2.0.0-beta.51 (2.0.0-beta.52)
    @vuepress/plugin-container:  2.0.0-beta.52
    @vuepress/plugin-docsearch: 2.0.0-beta.51 => 2.0.0-beta.51
    @vuepress/plugin-external-link-icon:  2.0.0-beta.52
    @vuepress/plugin-git:  2.0.0-beta.52
    @vuepress/plugin-google-analytics: Not Found
    @vuepress/plugin-medium-zoom:  2.0.0-beta.52
    @vuepress/plugin-nprogress:  2.0.0-beta.52
    @vuepress/plugin-palette:  2.0.0-beta.52
    @vuepress/plugin-prismjs:  2.0.0-beta.52
    @vuepress/plugin-pwa: Not Found
    @vuepress/plugin-pwa-popup: Not Found
    @vuepress/plugin-register-components: Not Found
    @vuepress/plugin-search: 2.0.0-beta.51 => 2.0.0-beta.51
    @vuepress/plugin-shiki: Not Found
    @vuepress/plugin-theme-data:  2.0.0-beta.52
    @vuepress/plugin-toc: Not Found
    @vuepress/shared:  2.0.0-beta.51 (2.0.0-beta.52)
    @vuepress/theme-default:  2.0.0-beta.52
    @vuepress/utils:  2.0.0-beta.51 (2.0.0-beta.52)
    vue:  3.3.1
    vue-loader: Not Found
    vue-router:  4.2.0
    vuepress: 2.0.0-beta.51 => 2.0.0-beta.52
    vuepress-vite:  2.0.0-beta.52
    vuepress-webpack: Not Found

I thin you are talking about missing headers, then we need a minimal reproduction with that file content

I've managed to get a reproduction repo set up: https://github.com/GreenImp/vuepress-dice-roller-test
You can reproduce the issue by running docs:dev and going to the Modifiers section; http://localhost:8080/guide/notation/modifiers.html
I have found that the issue only occurs when I have the diceRollerPlugin enabled in the Vuepress config.js. If I comment it out, everything works okay.
The diceRollerPlugin is a plugin I have written, which extends the markdown plugin. It reads markdown like this:
::: roll 6d10<=4 :::

And converts it into a VueJs component for rolling dice. the roll part is the keyword that the plugin picks up. The 6d10<=4 is optional, and you can just use roll by itself:
::: roll :::

It seems that it has issues rendering some headings that are after a ::: roll ... ::: bit, but not always. It seems random,
If I remove the ::: roll ... ::: before the heading, it then renders the heading in the menu.
If you look at the menu, the last item that shows up under the "Modifiers" header is "Target success / Dice pool ({cp})".
If you go to /docs/guide/notation/modifiers.md, line 434, and remove the ::: roll 6d10<=4 ::: just above the ## Target Failures / Dice Pool (f{cp}) heading, then that heading shows correctly.
I can't see a pattern, or reason that the plugin would stop the menu from rendering correctly, so hopefully you're able to help.
I'm not certain if it's a problem with my plugin, or with Vuepress.
For reference, the Vuepress plugin is: https://github.com/dice-roller/vuepress-plugin
And internally, it uses: https://github.com/dice-roller/vue

Another update;
In my Vuepress Plugin, I am using extendsMarkdown to render my component:
https://github.com/dice-roller/vuepress-plugin/blob/d336b643736daf1039dd2576571991a85da938d7/src/node/diceRollerPlugin.js#L23-L25
It seems to be a problem with the md.use() call. Specifically, with the name argument, 'roll':
md.use(markdownItContainer, 'roll', { render });

If I change roll, to something else (e.g. 'rolls'), and change the calls in the markdown to match, then it works;
::: rolls 4d6 :::

Is the name roll somehow breaking the things?

I have no interest without a minimal reproduction, but you should be extra carefull whether you write a correct plugin.
If your plugin does not generate everything correctly, but doing the following, the all headings are expected being omitted :

  <dice-component />

  ...

xxx

  ...

I've updated the repo and so it only has a single readme.md file now.
I also think that I've figured out what part of the issue is;
The markdown-it-container plugin expects the closing code fence to be on a different line to the start one. It doesn't understand inline code fences.
So, when doing this:
::: roll :::

It thinks it hasn't been closed, and then auto-closes the tag at the end of the document.
Whereas, if I move the closing fence to the next line down, then it works:
::: roll
:::

There is a ticket raised for the markdown-it-container, but the devs have dismissed it as not a bug. However, I think the spec suggests otherwise: https://spec.commonmark.org/0.18/#example-95
However, all of that being said, I'm not sure why it should be an issue in this situation, because my plugin doesn't have a closing tag, so the markup should still be valid. So I'm not sure if this is an issue with Markdown it, or Vuepress, or if I'm misunderstanding how it should work.
My render() method passed to the markdown-it-container basically does this:
const render = (tokens, idx) => {
    const { nesting } = tokens[idx];

    if (nesting === 1) {
        // opening tag - self closing
        return `<DiceRoller />`;
    }

    // closing tag
    return '';
};

So there is no opening tag that needs closing, and when it auto-closes at the end of the document, it should just output an empty string anyway.
You can also see that the DiceRoller component that it loads has all of the correct closing tags and valid markup: https://github.com/dice-roller/vue/blob/dbca48140dbcf1b7335488b1853e0c1f5d34b600/src/components/DiceRoller.vue

You don't understand example 95 at all, that has nothing related to fence.
The container is acting expected.
Auto closing the token at last means all content later is inside your dice token, so they are regarded as ui headings instead of documentation heading (nesting depths must be 0)
I think I explained everything. New discussion if you jave further problems.

authors: GreenImp Mister-Hope

repo: vuepress/vuepress-next


text:
404 for numeric markdown files such as 911.md

[x] I confirm that this is an issue rather than a question.

Bug report
Steps to reproduce

[x] I prepared a reproduction repo, here is the reproduction repo: https://github.com/shinjawkwang/techArchive/tree/gh-pages

[ ] This issue doesn't need a reproduction repro, here is the steps to reproduce

What is expected?
The repo is deployed by github page, and I mixed base-list-layout in @vuepress-theme-default. When accessing numeric-named pages such as /daily-coding/2020/01/23/_1927, the rendered markdown page is expected to appear.
What is actually happening?
The numeric-named page(/daily-coding/2020/01/23/_1927) returns 404, only at github-page deploy. This symptom doesn't appear when locally deployed or access the page by sidebar-link of theme-default at another page, whose file name is english.
Other relevant information

npx vuepress info: Environment Info:
System:
OS: Linux 4.14 Ubuntu 19.04 (Disco Dingo)
CPU: (16) x64 Intel(R) Xeon(R) CPU @ 2.20GHz
Binaries:
Node: 10.18.0 - ~/.nvm/versions/node/v10.18.0/bin/node
Yarn: 1.21.1 - ~/.nvm/versions/node/v10.18.0/bin/yarn
npm: 6.13.4 - ~/.nvm/versions/node/v10.18.0/bin/npm
Browsers:
Chrome: Not Found
Firefox: Not Found
npmPackages:
@vuepress/core:  1.4.0
@vuepress/theme-default:  1.4.0
vuepress: ^1.2.0 => 1.4.0
npmGlobalPackages:
vuepress: Not Found

Sorry for the late response.
Were you saying that files such as/daily-config/2020-01-23-_1927.md won't work fine? And it's only happening at gh-page deploy?

No, the file name is like /daily-coding/2020-01-23-1927.md, no _ at filename, and it's happening on gh-page deploy.
After open issue, I found that not numeric-only file, but numeric-starting file doesn't work. For example, ~/2020-01-23-1023-foo/ doesn't work and ~/2020-01-23-foo-1023/ works.

All right. It seems because Github Pages somehow doesn't support _ prefix files.
Solution. You can fix it by simply adding a file named .nojekyll in public folder.

BTW, I should use <router-link> rather than  <a>. I found it when I checked out your repo.
// docs/.vuepress/components/ListLayout.vue
<a :href="'/techArchive'+page.path">{{ page.title }}</a> // -

<router-link  :to="page.path">{{ page.title }}</router-link> // +

That works well! Thank you very much for kind explain :)

repo: vuepressjs/vuepress-plugin-blog


text:
Possibility for user to change binning in plots

Possibility for the user to change energy binning in plots

[ ] angular resolution plots
[ ] energy resolution plots
[ ] effective area

bins=None to keep default binning

repo: vuillaut/ctaplot