A rejected promise in  in a notFoundComponent is not caught by the defaultErrorComponent

Which project does this relate to?
Router
Describe the bug
I‘m using <Await> to fetch some data in a notFoundComponent. When using renderToPipeableStream() I can see the following object has been thrown and not caught by an error boundary:
{
  data: { data: { data: [Object], __isServerError: true } },
  __isServerError: true
}

Your Example Website or App
https://stackblitz.com/edit/github-yk78pg-wpq5bb
Steps to Reproduce the Bug or Issue

checkout the example
run npm i
run npm run compile
run node dist/main.js

Expected behavior
I would expect:

the defaultErrorComponent being invoked with the rejected promise from <Await />
to get an actual instance of Error instead of the serialized server error object

Screenshots or Videos
No response
Platform

Version: 1.52.4

Additional context
No response

Please attach a valid minimal reproduction showing off the issue in question.
You can fork our Stackblitz starter to make the setup process easier - https://stackblitz.com/github/tanstack/router/tree/main/examples/react/quickstart-file-based

This issue only happens during server-side-rendering. So I’ve used basic-ssr-file-based as an example. See https://stackblitz.com/edit/github-5vsdzx
What has been changed:

the index route has a loader which directly throws notFound()
the router has a defaultErrorComponent which also logs the props to the console
the root route has a notFoundComponent which use <Await> to wait for a promise that always rejects

Steps to reproduce:

start the example on stackblitz (which should happen automatically or via npm install && npm run dev

Note: in case of the stackblitz browser just renders "Upgrade Required", try to click the link in the terminal within the log message: Client Server: http://localhost:3000

-> Once the the dev server loads the index page in the browser it immediately crashes
-> the following error should be visible in the terminal

{
 data: { data: { data: [Object], __isServerError: true } },
 __isServerError: true
}
Error: 💣

An <Await> with a Promise is not something typically found in a notFoundComponent.
@lo1tuma what's your expectation as to what's supposed to happen here?
@tannerlinsley what's Start's desired expectation here?

An <Await> with a Promise is not something typically found in a notFoundComponent.

See also this discussion I’m basically looking for a unified way to load data in a notFoundComponent.

@lo1tuma what's your expectation as to what's supposed to happen here?

My expectation would be that the error is getting caught and instead of rendering the notFoundComponent the errorComponent should get rendered.


Add iniscan ?

Not entirely sure if this is a good match (less useful on a dev environment and only occasionally needed on a production machine) but https://github.com/psecio/iniscan might be a useful addition.

Looks useful to me 👍
You could test provisioned development environments and/or your custom/own PHP installation.

looks like it doesn't support /etc/php.d/ style config. but that's fixable.

@wouteroostervld Well spotted!
Seems like the repository is kinda unmaintained... Could be fun to pick up a fork :)

@Potherca This one is open for some time already.
While I really like the idea of this tool, it is kinda unmaintained and even more important: It does not support multi file / dir configurations (which is kinda de default nowadays).
I would like to suggest closing this ticket.

As discussed, this is not a tool for the developer, this is more like a "devops" tooling.
Closing this issue for now.


Update Composer dependencies (2022-09-16-00-07)

Visual regression test passed!
View the visual regression test report


Proof of concept: plugin architecture based on event bus + plugin listeners, using go-plugin

What is the purpose of this change? What does it change?
This proof of concept takes the work accomplished in #1173  and changes the underlying mechanism to use hashicorp/go-plugin instead, using plain RPC.
Was the change discussed in an issue?
No.
How to test changes?

Go to a directory outside of your $GOPATH (unless you know how to deal with go modules installed in $GOPATH)
git clone https://github.com/metacosm/odo-tracer-listener.git
cd odo-tracer-listener
git checkout go-plugin
go build -o tracer.listener.odo listener.go
mkdir -p ~/.odo/plugins/ (if you don't already have that dir)
cp tracer.listener.odo ~/.odo/plugins/
Build this PR and issue an odo command that uses the new oc command pattern (any service, catalog or link/unlink commands, only these commands are automatically wired to dispatch events)
You should see some plugin-related debugging messages
Check ~/.odo/plugins/tracer.log to see the logging performed by the tracer plugin.

Note: It might happen that the command you issued failed with an error and you might need to check that the plugin process is not still running: ps aux | grep tracer and then killall tracer.listener.odo. Basically, plugins are "managed" and need to be cleaned-up before the application exits. This is done by a deferred call in the main odo function. However, calls to os.Exit don't run deferred functions. I have added some code to perform plugins clean up before some calls to os.Exit but might have missed some, which might lead dangling plugin processes running (basically a server process). A proper solution to this issue will have to be devised.

supporting component CRD work without impacting the odo core.

another use cases could be to :

audit, log what odo is doing
scaffold a project (spring boot, vertx, tornthail, ....)
export resources : helm chart, openshift template, ...

:white_check_mark: odo build 1423 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/e96682a99b by @metacosm)

Extremely difficult to review the PR...
Can we plan a session where you can walk the reviewers through the code?

I would be interested in a session as well

+1 to have a meeting with Christophe
On Mon, Feb 11, 2019 at 1:27 PM Georgios Andrianakis <
<EMAIL_ADDRESS>wrote:

I would be interested in a session as well
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/redhat-developer/odo/pull/1235#issuecomment-462310232,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcTro3XTQrfrpoWfl0UVyNL4uazcl5Lks5vMWGcgaJpZM4aUQP-
.

--
Charles Moulliard
Apache Committer & PMC / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io

:white_check_mark: odo build 1587 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/3f1deece37 by @metacosm)

This PR as of now needs alot of work due to the major changes in odo. It would be better if a new PR using the current master is created at a later point when plugins become priority.


Can you please set the animation effect of dialog?

[ ] I have verified there are no duplicate active or recent bugs, questions, or requests
[ ] I have verified that I am using the latest version of Material Dialogs.
[ ] I have given my issue a non-generic title.
[ ] I have read over the documentation (before asking questions on how to do something).

Include the following:

Material Dialogs version: 0.x.x.x
Device OS version: 7.1.1
Device Manufacturer: Google
Device Name: Pixel XL

Also, please wrap Java with correct syntax highlighting.
System.out.println("Hello, world!");

Reproduction Steps

Expected Result
Actual Result

MaterialDialog inherits android.app.Dialog so you can do any animations with this library that you could do with stock dialogs.
I don't plan to add any additional special support for it.


No status indicators on a remote cluster

Status indicators appearing in the module definition are not copied to the blueprint structure, thus Blueprint controller running on the remote cluster does not access the correct indicators and reports true even when there were failures in the orchestrated resource.

I am not sure that copying the module definitions all the way to the remote blueprints is the right way to do this. Besides, once we wanted to copy the spec chart values from the remote modules to be able to define things differently in different locations. Worth discussion. Closing this for now.


self._raw_data and self._sparse_data in fit method of UMAP class

Raw data
I observed that self._raw_data is defined two times in the fit method of the UMAP class:
https://github.com/lmcinnes/umap/blob/23e6af696ef715c21655faa7cdefb7d44a5f9d0c/umap/umap_.py#L1334
https://github.com/lmcinnes/umap/blob/23e6af696ef715c21655faa7cdefb7d44a5f9d0c/umap/umap_.py#L1404
I was wondering whether it is intended or not. The first time is always run, but the second time is only run if not X.shape[0] < 4096:.
Sparse data
https://github.com/lmcinnes/umap/blob/23e6af696ef715c21655faa7cdefb7d44a5f9d0c/umap/umap_.py#L1349-L1353
if scipy.sparse.isspmatrix_csr(X) and X.has_sorted_indices: will give self._sparse_data = False. I am not sure that it is intended since X.sort_indices() will sort the indices of X in place and then you will have self._sparse_data = True. I'm not very familiar with sparse matrices though, I may have missed something.
Best regards

These seem like errors. I'll try to clean things up soon (or you are
welcome to submit a PR if you wish).
On Mon, Aug 6, 2018 at 8:23 AM Johann Faouzi<EMAIL_ADDRESS>wrote:

Raw data
I observed that self._raw_data is defined two times in the fit method of
the UMAP class:
https://github.com/lmcinnes/umap/blob/23e6af696ef715c21655faa7cdefb7d44a5f9d0c/umap/umap_.py#L1334
https://github.com/lmcinnes/umap/blob/23e6af696ef715c21655faa7cdefb7d44a5f9d0c/umap/umap_.py#L1404
I was wondering whether it is intended or not. The first time is always
run, but the second time is only run if not X.shape[0] < 4096:.
Sparse data
https://github.com/lmcinnes/umap/blob/23e6af696ef715c21655faa7cdefb7d44a5f9d0c/umap/umap_.py#L1349-L1353
if scipy.sparse.isspmatrix_csr(X) and X.has_sorted_indices: will give self._sparse_data
= False. I am not sure that it is intended since X.sort_indices() will
sort the indices of X in place and then you will have self._sparse_data =
True. I'm not very familiar with sparse matrices though, I may have
missed something.
Best regards
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lmcinnes/umap/issues/107, or mute the thread
https://github.com/notifications/unsubscribe-auth/ALaKBZJzKst03sYiDXRSo5Z9n8GCsmJ9ks5uODVdgaJpZM4VwSlD
.

Merged, thanks.


Check the list of repos for specific files

Issue Summary
We have a list of files that we would like to see in every repository, it would be great to be able to add information to the database so that a file-statuses dashboard can be built.
This should:

Reach out to the repos and look at the expected file list
See if the files in the "expected files list" exist in the repo
Update the database with the status of the files from the list

Here's the default file list that we currently search for:

./Docker or docker/Docker
./docker-compose.yml or ./docker/docker-compose.yml
./.env_sample
./.gitignore
./.travis.yml
./.codeclimate.yml
./CHANGELOG.md
./CODE_OF_CONDUCT.md
./CONTRIBUTING.md
./.github/ISSUE_TEMPLATE
./LICENSE.md
./.github/PULL_REQUEST_TEMPLATE
./README.md
./TROUBLESHOOTING.md
./USAGE.md
./USE_CASES.md

Mind if i get this one?


Stringify [githublanguagecount] message

This is also related to the changes in #7877.

Warnings

:warning:
This PR modified service code for github but not its test code. That's okay so long as it's refactoring existing code.

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @paulmelnikow!

  Generated by :no_entry_sign: dangerJS against 3e400ef8bff11a0973a60458c7812bb283ebfb7f


Issue with RECONNECT in PubSub

Got in my project log:
2023-02-24 18:59:03 [T:MainThread] DEBUG:twitchio.ext.pubsub.websocket: Pubsub event referencing unknown event 'RECONNECT'. Discarding
It's expected (according to the current Twitch docs) that RECONNECT has own type in received message. The straightforward solution would be move this to method handle_reconnect.

Thanks, we are aware of this already and is currently in testing before we commit.


Changed shell executions to use non-deprecated methods

Currently, both the PowerShell and CMD shell executions are using deprecated APIs
to do so. As a result, each time you use this plugin, a warning is logged that
you are using a deprecated API. I have changed the plugin to use the new,
non-deprecated APIs for both PowerShell and CMD execution that were introduced
in WinRb WinRM 1.5.0. To clarify, the change that I have made is still functionally equivalent to what was being done before, but will no longer result in a warning being logged due to use of a deprecated API.

Thanks


Missing SPDX file :-)

Just as the cobbler forgets to repair his own shoes, most SPDX sponsored projects seem to be missing an SPDX desciption file for the project.
Need an SPDX file (files?) unless you think the SPDXParser.spdx file covers this though it isn’t intuitive. Would think an SPDX folder might work or standard naming (project.spdx, package.spdx) something to describe scope of applicability?

On Tue, Aug 08, 2017 at 10:51:17PM -0700, stcroppe wrote:

Need an SPDX file (files?) unless you think the SPDXParser.spdx file
covers this…

In benbalter/licensee#85, @david-a-wheeler suggested LICENSE.spdx, and
that seems like a good choice to me.

Would think an SPDX folder might work or standard naming
(project.spdx, package.spdx)…

The spec also uses package.spdx in an example 1, so I think that
would be a good choice as well.

SPDXParser.spdx is indeed an SPDX file for this project.  It is a bit out of date.  I'll update it it on the next release and rename it to package.spdx as suggested.  I'll leave this issue open until the changes are made.
BTW - on my long list of todo's is to use Anna's github spdx project to generate the SPDX document using a Maven plugin on code checkins.  It may take a while to get this operational since I need to setup and host a server and update the build process to support it.

I think LICENSE.spdx is the better name. Many tools and documents already say that files named LICENSE are special.

I would like to bring this to SPDX tech team mailing list to get some additional feedback before renaming the file.
I'm assuming this is a discussion for a best practice for naming SPDX files within a repository (as opposed to naming SPDX files for a tool output or on a listing of SPDX documents in some external folder or website).
Current options:

LICENSE.spdx
package.spdx
project.spdx
[packagename].spdx (where [packagename] is the name of the package

Let me know if you would like to alter/add to the scope or options.

I very much like the LICENSE.spdx option as well – it pops out, is more descriptive than other suggestions, and as @david-a-wheeler mentions, it looks like something both a human (or a tool) would be looking for.
The only downside I can see is that SPDX contains also technical info and maybe in the future those will be as interesting as the legal info stored in the same file.

I am +1 for using LICENSE.spdx, it's already challenging to get devs to add a LICENSE to their project. To maximize the adoption of SPDX I believe LICENSE.spdx is easy to explain as human and machine readable version of LICENSE a.k.a v2.0 of LICENSE.  Opened similar ticket (https://github.com/spdx/spdx-spec/issues/19) for the SPDX specification repository

LICENSE.spdx is also what we recommend for REUSE compliance https://reuse.software/ and seems sensible considering the primary use.

I would like to bring this to SPDX tech team mailing list to get some additional feedback before renaming the file.

Linkin that thread, which was pretty quiet.

Closable with e6eed31892cbe in master?

Agreed.

Good decision. :-)


Unable to sign app

Facing an issue after verification step. My keystore file does not have the .jks extension, instead it has the .keystore extension, but I was still able to base64 encode it. I've triple checked that my alias and keystore password was correct. I left out the key password option and I tried setting it to an empty string as well since I don't have a key password for my keystore. Any idea what I'm doing wrong? Does this action support keystores that have a keystore password, but do not have a key password?
Verification succesful
/usr/local/lib/android/sdk/build-tools/29.0.2/apksigner sign --ks android/app/build/outputs/apk/release/signingKey.jks --ks-key-alias *** --ks-pass pass:*** --key-pass pass: --out android/app/build/outputs/apk/release/app-release-signed.apk android/app/build/outputs/apk/release/app-release-aligned.apk
Failed to load signer "signer #1"
java.io.IOException: Failed to obtain key with alias "***" from android/app/build/outputs/apk/release/signingKey.jks. Wrong password?
	at com.android.apksigner.SignerParams.loadPrivateKeyAndCertsFromKeyStore(SignerParams.java:320)
	at com.android.apksigner.SignerParams.loadPrivateKeyAndCerts(SignerParams.java:181)
	at com.android.apksigner.ApkSignerTool.sign(ApkSignerTool.java:277)
	at com.android.apksigner.ApkSignerTool.main(ApkSignerTool.java:83)
Caused by: java.security.UnrecoverableKeyException: Cannot recover key
	at sun.security.provider.KeyProtector.recover(KeyProtector.java:315)
	at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:141)
	at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
	at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
	at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
	at java.security.KeyStore.getKey(KeyStore.java:1023)
	at com.android.apksigner.SignerParams.getKeyStoreKey(SignerParams.java:375)
	at com.android.apksigner.SignerParams.loadPrivateKeyAndCertsFromKeyStore(SignerParams.java:288)
	... 3 more
##[error]The process '/usr/local/lib/android/sdk/build-tools/29.0.2/apksigner' failed with exit code 2

Seems like it had to do with the key password being required.
Made a PR here and tagged with 1.1.0. Feel free to edit/decline. In the meantime I will be using my forked version. Thanks for this action!
https://github.com/r0adkll/sign-android-release/pull/3

Merged!


Add hungarian translation

Thanks for this translation, @asrob! I'll merge this in now and it will be part of the next release.


Add support for downloading all submitted student code for a course

For exams, we need to be able to download (clone) all repos and also to download all repos as zip balls for archival purposes.
This function can possibly be used: GetZipballURL.
However, check if this specifically needs the student to perform a release. Ideally, we only want the student to push their final version...

This could be a feature of the tool proposed in #562.

Moved this as #562 (comment).


Address StyleCop warnings for TabInfo and TabIndexer

I did the best I could on the documentation, but some of those properties I don't use and don't know the ins and outs of them.  Maybe @donker or @sleupold could provide some more details on the language GUIDs, perhaps.


Fix sidebar

When sidebar is longer then the page content, it's tail is hidden.

This fixes it, check https://knplabs.github.io/Gaufrette/

Seems legit for me ;)

I'm sorry but I don't think it can be merged:

it would break BC/change the website for projects already using this template
it would make the menu less nice - it was a voluntary choice to make the menu floating knowing it would have been a limitation on big menus (e.g. http://myclabs.github.io/Work/)

The assumption behind this template is that it's designed for small project, or to get started very quickly. For bigger projects (like Gaufrette) I'm 100% convinced that it's better to copy this template as a starting base inside the project itself and customize it. Is that good for you?

it would break BC/change the website for projects already using this template

Is there a versioning suppot?

it would make the menu less nice.

Can you please point me at the difference, because I didn't notice c change in how menu looks?

For bigger projects (like Gaufrette) I'm 100% convinced that it's better to copy this template as a starting base inside the project itself and customize it.

I did that, just hoped it is a temporary solution until this gets merged. :)

Is there a versioning suppot?

No, at least not in the sense "we can tag a v2.0 and projects will keep using v1".

Can you please point me at the difference, because I didn't notice c change in how menu looks?

Well the menu isn't fixed anymore. You can go for example on http://myclabs.github.io/Work/ and apply the change of this PR using developer tools to see. I originally made the menu fixed for a reason, "it's not a bug, it's a feature" :p
The situation is actually a bit funny: if we merge this, that means we are OK to break things, so that means that using that template for Gaufrette means that the website could break/change in the future. If so, you would naturally conclude that you should copy the template in the project to protect yourself from breaking changes, hence removing the need to merge the PR at all! (sounds a lot like a time-travelling paradox!)
From a maintainer's perspective I'm convinced you'd be better off including the template in your project if it's a "serious" project like Gaufrette (compared to the other project I linked to which is much much less popular and don't justify the same "effort").

Yes, I see your point.
Thanks for the response.

:+1: let us know if you have more questions


Update CI to codecov-action v2

As mentioned in: https://github.com/codecov/codecov-action , codecov-action@v1 will be deprecated/sunset on February 1, 2022.
There are a few breaking changes mentioned in the codecov-action README.md, but I don't think this workflow uses any of the breaking changes mentioned.

CI tests pass, (though percy has some visual changes for review?)


Cleanup RKE state directory

https://github.com/rancher/rancher/issues/21976
When adding logging, this was the output for the current code:
2021/05/07 22:11:52 [DEBUG] Going to remove state directories: [management-state/rke/rke-445186939/cluster.yml] [management-state/rke/rke-445186939/kube_config_cluster.yml] [management-state/rke/rke-445186939]
2021/05/07 22:11:52 [ERROR] Error while deleting [management-state/rke/rke-445186939/cluster.yml], remove management-state/rke/rke-445186939/cluster.yml: no such file or directory
2021/05/07 22:11:52 [ERROR] Error while deleting [management-state/rke/rke-445186939], remove management-state/rke/rke-445186939: directory not empty

Which I guess is because the code was never edited to take care of the state file that got added at some point. I also changed from removing every individual file to removing the directory and everything in it.

hi @superseb,  I still haven't upgraded my rancher to a version that has this fix. Is it safe to just "rm *" under .../management-state/rke/ to clean up some space?

hi @superseb, I still haven't upgraded my rancher to a version that has this fix. Is it safe to just "rm *" under .../management-state/rke/ to clean up some space?

i deleted files older than 30 days and cluster works without issues


Unable to open modal from dropdown

I have three components - app, sideNav and wallForm. In the app header, I have a button that drops down the sideNav. The sideNav has an add button which opens the wallForm modal. This is an ng2-bootstrap modal. The drop down menu loads fine, but when I click on the add button, the modal loads and the screen greys out (disabled), but the modal does not show in the front. I know it has loaded because I can inspect the element in browser developer tools. I tried setting the z-index of the modal to a very high number, much higher than that of the drop down menu and that didn't help. How do I get the modal to behave as it should i.e., display on top?

try to check this one https://github.com/valor-software/ng2-bootstrap/issues/1462#issuecomment-272226598
closing as duplicate

My issue remains unsolved. The navbar had position set to relative and I changed that to fixed. Now, when I click add button, nothing happens. It doesn't even grey out the background. Can this issue please be reopened?

Can you create a sample to reproduce?

Same problem here, can't open a modal dialog from my dropdown menu.
I only see the backdrop but no dialog.

I'm also facing the same problem. The modal isn't opening when clicked from a dropdown menu. Is there any workaround for this problem?

Hi, i'm unable to open (correctly) the modal by clicking a button inside a carousel as well using template reference binding.
if there's a service to separate the trigger and the modal div into different component that would be helpful cause the bug is that when putting the modal div inside the carousel, the modal wouldn't open correctly, there's few example on other thread but the code is outdated and not really applicable anymore using the latest angular 2 codes. please advise thanks!

@shilpaprabhun ok, I have found what the problem is:
inheritance of z-index, but it could be solved only inside of your markup
what I can do: I am implementing modal service
it should simplify modals usage


Can't build a module using Owl_stats_dist in dune, works in utop (arm64 mac)

This is weird
I have a module that has this code
let point () =
  Gg.V3.v
    (Owl_stats_dist.std_uniform_rvs ())
    (Owl_stats_dist.std_uniform_rvs ())
    (Owl_stats_dist.std_uniform_rvs ())

This works fine in dune utop for same project:
utop # # require "owl";;

utop # Owl_stats_dist.std_uniform_rvs ();;
- : float = 0.815008172023810484

But when I try to build my module with dune I get:
Undefined symbols for architecture arm64:
  "_sfmt_state", referenced from:
      _owl_stub_std_uniform_rvs in libowl_stubs.a(owl_stats_dist_stub.o)
      _owl_stub_uniform_int_rvs in libowl_stubs.a(owl_stats_dist_stub.o)
      _beta_rvs in libowl_stubs.a(owl_stats_dist_beta.o)
      _binomial_rvs in libowl_stubs.a(owl_stats_dist_binomial.o)
      _dirichlet_rvs in libowl_stubs.a(owl_stats_dist_dirichlet.o)
      _std_exponential_rvs in libowl_stubs.a(owl_stats_ziggurat.o)
      _std_gaussian_rvs in libowl_stubs.a(owl_stats_ziggurat.o)
      ...
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
File "caml_startup", line 1:
Error: Error during linking (exit code 1)

Seems strange that it should work in utop but not in dune?
I have owl 1.1.0 pinned to github due to #625

Also... is Owl_stats_dist.std_uniform_rvs the best method for getting a single random float from uniform distribution?  It's the one I found


Provide a fully embedded WinRT interop option

There are scenarios where the developer would like to use a WinRT API without polluting/altering their dependencies. This could potentially be limited to cases where the usage of the WinRT API is entirely internal to the library.
It would be nice if the CsWinRT tool could provide a comprehensive WinRT interop scenario, that is internal to the assembly, in the form of just source code - no WinRT.Runtime.dll dependency.
/cc @jkotas @richlander @clairernovotny

To extend this a bit, it would also be interesting to see this on a namespace scope as well.

For the embedded scenario, here's a quick writeup of the proposal discussed over email:
Provide a Microsoft.CsWinRT.Runtime.Embedded.Sources package that has cswinrt.exe, a copy of the WinRT.Runtime sources all marked as internal with modifications to not register the ComWrappers instance globally, and a file that includes an attribute, [assembly:IncludesEmbeddedWinRTProjection]. When the WinRT.Runtime code tries to look up a type from its WinRT name, it will first check if the assembly it is in has this attribute. If it does, it will only search this assembly and the (local copy of the) type mapping registrations for the type. If it doesn't have the attribute, it will search every loaded assembly (as is the current behavior today) except assemblies with the IncludesEmbeddedWinRTProjectionAttribute attribute. As a result, embedded WinRT projections will only know about the types that were projected with them, and the global projections will be discovered correctly by the global ComWrappers instance.

Clearing the milestone on this based on current timeline & resourcing.

With .NET Core 3.1, I was able to use reflection to detect access to WinRT APIs and light them up if I'm running on Windows. This was great because I relied on WinRT APIs available since Windows 8.0.
With .NET5, reflection to WinRT is no longer supported, and the only way to call WinRT APIs are by targeting net5-windows10.0.17763. This works great for building windows apps, but it works pretty poorly for building cross-platform .NET apps, or building class libraries. Sure I can multi-target, but I'd prefer just targeting net5, because if a user is targeting net5.0 or even net5.0-windows, it'll fallback to the netcoreapp3.1 assembly which is likely still using reflection into WinRT APIs and will fail on .NET 5. I covered some of that here: https://github.com/microsoft/CsWinRT/issues/458
My thought was to build my own WinRT Projection and embed into my assembly, and throw some try/catch and OS checks around it, so I that way would detect support for those APIs and use them. However I didn't have much luck with that.
So I made the following project to get access to GeoLocation APIs, and compiled it:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.CsWinRT" Version="0.8.0" PrivateAssets="All" />
  </ItemGroup>
  <PropertyGroup>
    <CsWinRTIncludes>
      Windows.Devices.Geolocation;
      Windows.Foundation.Metadata.ContractVersion;
      Windows.Foundation.UniversalApiContract;
      Windows.Foundation.Metadata.DualApiPartition;
      Windows.Foundation.Metadata.MarshalingBehavior;
      Windows.Foundation.Metadata.MarshalingType;
      Windows.Foundation.Metadata.Activatable;
      Windows.Foundation.Metadata.Static;
      Windows.Foundation.Metadata.Threading;
      Windows.Foundation.Metadata.ThreadingModel;
      Windows.Foundation.Metadata.Muse;
      Windows.Foundation.Metadata.ExclusiveTo;
      Windows.Foundation.Metadata.ApiContract;
      Windows.Foundation.Metadata.AttributeName;
      Windows.Foundation.Metadata.AllowMultiple;
      Windows.Foundation.IAsyncOperation;
      Windows.Foundation.TypedEventHandler;
      Windows.Foundation.UniversalApiContract;
      Windows.Foundation.FoundationContract;
      Windows.Foundation.IAsyncInfo;
      Windows.Foundation.IAsyncAction;
      Windows.Foundation.AsyncStatus;
      Windows.Foundation.AsyncActionCompletedHandler;
      Windows.Foundation.AsyncActionProgressHandler;
      Windows.Foundation.AsyncActionWithProgressCompletedHandler;
      Windows.Foundation.AsyncOperationProgressHandler;
      Windows.Foundation.AsyncOperationCompletedHandler;
      Windows.Foundation.AsyncOperationWithProgressCompletedHandler;
    </CsWinRTIncludes>
    <CsWinRTGeneratedFilesDir>$(OutDir)</CsWinRTGeneratedFilesDir>
    <CsWinRTWindowsMetadata>sdk</CsWinRTWindowsMetadata>
    <CsWinRTGenerateProjection>true</CsWinRTGenerateProjection>
  </PropertyGroup>
</Project>

However, because it generates public classes, but the WinRT.cs and WinRT_Interop.cs files have all types internal (but those types are exposed in the generated classes) I get the following build errors:,
`>\obj\Debug\net5.0\Generated Files\Windows.Foundation.Metadata.cs(30,16,30,36): error CS0051: Inconsistent accessibility: parameter type 'Platform' is less accessible than method 'ActivatableAttribute.ActivatableAttribute(uint, Platform)'
1>\obj\Debug\net5.0\Generated Files\Windows.Foundation.Metadata.cs(33,16,33,36): error CS0051: Inconsistent accessibility: parameter type 'Platform' is less accessible than method 'ActivatableAttribute.ActivatableAttribute(Type, uint, Platform)'
1>\obj\Debug\net5.0\Generated Files\Windows.Foundation.Metadata.cs(114,16,114,31): error CS0051: Inconsistent accessibility: parameter type 'Platform' is less accessible than method 'StaticAttribute.StaticAttribute(Type, uint, Platform)'

My main problem in the first place is that it generates public classes. I want them all to be internal, as I don't actually want to expose these methods, (doesn't seem like the source generator has that option) but just use them internally in a light-up way. There's just no reason to embed WinRT types and expose them in your class library - if you needed that in your app, just target the TFM that include WinRT APIs.
I then took the generated code from the obj folder and embedded them in a class library, and changed all public classes to internal. Now things actually do compile, but sadly I'm getting bad crashes at runtime, and in addition I'm forced to deploy a WinRT dependency as well (Microsoft.Windows.CsWinRT).
            WinRT.ComWrappersSupport.RegisterProjectionAssembly(typeof(Program).Assembly);
            Geolocator g = new Geolocator(); //OK
            g.DesiredAccuracy = PositionAccuracy.Default; // BOOM!

I have the use case of "the usage of the WinRT API is entirely internal to the library". I abstract the Bluetooth LE Stack (I have four implementations in the project) and WinRT is one of the implementations. Currently the TFM net5.0-windows.... of .NET is forcing itself into the application domain which I would prefer to have a single TFM (net5.0). I tried an AssemblyLoadContext Plugin approach which worked, however, the consequent packaging is just an unneeded hassle.

Embedded support is now available with C#/WinRT v1.4.1! These docs and samples provide more details on how to use the support.


Release Notes

A few small updates in the last few weeks.
Version 3.14.1

The AB is now a W3C group (I really need to move this data to bikeshed-data rather than in the Python...)
(temporarily) allowed CR as whitespace, to fix a confusing parse error that some people were getting.

Version 3.14.2

Made = in unquoted attribute values not an HTML parse error, so you can still have unquoted URLs with query strings in your attributes. (This'll be partially reverted in a future version, as the parse error apparently legitimately catches a lot of problems in the wild where people accidentally omit the space between two unquoted attributes, but I'll keep the exception for attributes known to contain URLs, like href and src.)

Version 3.14.3

reverted the CR change from 3.14.1, instead properly normalized linebreaks when the source file comes from a URL. Turns out requests doesn't do this for you, while the rest of Python file loading does.

Version 3.14.4

Added a Die On metadata, paralleling the --die-on command-line flag, that controls what level of error message results in the spec failing to build entirely. No change to existing documents (it still defaults to "fatal"), and the command-line flag still overrides anything coming from metadata.
Allowed W3C Community Groups to use the w3c/UD status, since it's an unofficial status anyway, and useful to distinguish from their "real" draft statuses.

Version 2.0.0

Feature: Added darkmode styles!
This is the reason for the version bump, as if you were adding your own styles to your document, they probably aren't darkmode-aware and will look bad when the readers are in darkmode. If you're just using Bikeshed's own styles, tho, everything will work exactly as before.

Feature: Added new conditional-inclusion feature, allowing you to remove sections of a spec (typically in boilerplate) based on the document's Status. If you have more things you want to base a conditional inclusion off of, let me know!
(Currently, the processing order of this happens after all the 'datablocks' (pre with special class that triggers Bikeshed handling) happens, so even if those are inside of a conditional that gets excluded, they'll still get processed. But everything else happens after conditional stuff is removed.)

Bugfix: The rest of IDL's built-in types are now autolinked.

Version 2.1.0

Feature enhancement: Conditional inclusion can now conditionalize on the presence of a custom boilerplate element (something with boilerplate=foo attribute) or the presence of a custom text macro, so you can include a chunk of related HTML only when the thing it's trying to refer to actually exists!

Feature: Autolink conjugations (the thing that lets you write [=applying=] when the original definition was just <dfn>apply</dfn> now apply to the first word of a phrase as well as the last. This will usually catch the verb in a multi-word phrase, like "apply the widget", so you can write [=applying the widget=] and have it Just Work. (But all the conjugations apply, so noun-headed terms like "widget controlled by the user" can be autolinked with [=widgets controlled by the user=] now.)

Feature: Biblio autolinks (like [[FOO]]) can now be switched into "inline" display mode, where rather than displaying as "[FOO]" and linking to the bibliography, they display as the actual document's title and link straight to them. (They still get added to the index.) You can turn it on individually with [[FOO inline]], or set the default for all biblios in the spec with Default Biblio Display (and switch them back to "index" mode with [[FOO index]]).

Bugfix: Better darkmode styles! Various fixes thruout, including to certain boilerplates.

Bugfix: bumped the versions for several dependencies to the most recent form, just for general dependency-hygiene reasons

Bugfix: If you used Editor Term to rename what the spec-metadata section called "Editors", various small side-effects that should specially trigger for the Editor lines... wouldn't. They do now.

Version 2.3.0
Whoops, didn't write release notes for the 2.2 versions! Oh well!

Feature: Global -a flag to force Bikeshed to emit ASCII-only in all its messages.

Feature: When using WPT Path Prefix with a lot of tests missing, don't spam the full list out, just log a warning that there are a bunch.

Feature: Biblio autolinks can now take the obsolete keyword to allow an intentionally-obsolete reference (otherwise Bikeshed complains and automatically switches your ref to what obsoleted it).

Feature: Finally got daily test updates working, so we run with the most modern set of specs rather than ones that are obsolete by months.

Bugfix: Stop ignoring certain test types from WPT, so any test can be linked.

Bugfix: Track what data files exist locally manually, rather than relying on the list matching what the remote data last contained.

Bugfix: Grab the correct set of boilerplates for the specified Status.

Misc: Lots and lots of fixes to make Bikeshed lint-clean.

 If your <img> elements don't already have width/height attributes on them, Bikeshed will do its best to auto-detect what the sizes are, and insert them into your markup automatically. This is a small but nice perf improvement for specs, avoiding layout-jiggle as images load in.

Version 2.4.0

Added the NOTE-ED, NOTE-WD, and NOTE-FPWD statuses, for handling the new somewhat-more-official "Note track" for W3C documents, so you can have boilerplates with appropriate verbiage to indicate it's a Note-track document.
Minor fixes to boilerplates and styles. Shouldn't be anything you notice, but if you're tracking diffs in your generated output you'll see some chatter.
Another banger from @frivoal, [<wpt> elements have some new features]:

<wpt hidden> processes the element but omits it from the output (useful for leveled specs that need to include all the tests in their folder so they can benefit from WPT Prefix, but don't actually have a place to put the tests for up/down-level versions)
<wpt title> lets you specify a descriptive paragraph for the tests in the block, formatting it just above the test list in the output
Multiple adjacent <wpt> elements will now be merged in the output
Best of all, rendered <wpt> elements are now <details> elements, and the new WPT Display: closed renders them closed by default (the previous inline value and its new alias open render them open by default, looking approximately the same as they previously did). The default styling for a closed <wpt> is a tiny out-of-the-way "TESTS", suitable for displaying even in live, published specs. Play with it for now, consider adding it to your defaults.include file. I plan to flip this to be the default in a near-future version.

Version 2.4.1

Several small boilerplate tweaks to some groups
 attribute is now parsed as Bikeshed source

Version 2.4.2

A few boilerplate updates, as always
Properly strip the internal-use attributes from <pre class=include-code> elements from the output document, so they won't cause your document to fail HTML validation.

Version 2.4.3

Boilerplates again.
A couple of widlparser dependency updates

lol been skipping release notes for a while!
Version 2.4.4

boilerplates again

Version 2.4.5

boilerplates
removed some ancient (and now incorrect) lines from the linking-defaults file

Version 2.4.6

accidentally did the previous release on Windows and picked up Windows line endings

Version 2.4.7

fixed the url link-defaults was pulled from during update!
boilerplates
bumped a lot of dependencies
fixed https://github.com/tabatkins/bikeshed/commit/3d037a4f7270476ea76fa4fd2d6ec406e33750aa, which caused text to get dropped in some circumstances

Version 3.0.0

New major version! Nothing exciting, I just pushed a breaking change for security reasons; you now have to explicitly opt-in, from the command line, to allowing Bikeshed to grab data from outside the input file's directory, or running arbitrary code via some extensions features.
biblio entries and links now use cite, such semantic https://github.com/tabatkins/bikeshed/commit/e4a654b463a551cb611500b18bd5f777e2103132
boilerplates

Version 3.0.1

boilerplates
actually lint the 3.0.0 code that restricted use of files outside the source directory

Version 3.0.2

boilerplates
some correctness fiddling to the 3.0.0 code

Version 3.0.3

??? I did literally nothing, weird.

Version 3.0.4

boilerplates (jeez I'm getting tired of this)

Version 3.0.5

boilerplates

Version 3.0.6

boilerplates

Version 3.1.0

NO MORE BOILERPLATES UPDATES. Bikeshed now stores and versions its boilerplates over at https://github.com/tabatkins/bikeshed-boilerplate, and brings in updates via bikeshed update like any other data files.

Version 3.2.0

fix a lot of lint errors from 3.1.0
propdef tables now link their "Applies To" header https://github.com/tabatkins/bikeshed/commit/980486aa7d3fc11d8711118c5938064b4e72a2cb
Issues lists (from bikeshed issues-list) can now have intro text https://github.com/tabatkins/bikeshed/commit/c2f0309eeade8c20550a4cbd08c79349f8fe7db1
Format links to GH issues better https://github.com/tabatkins/bikeshed/commit/8bb502091c0fa6a322c3b402ca297bf382715ecd
Added AOM as a group and megagroup, plus some new statuses for them

Version 3.3.0
Big new WPT features - inline test results!

<wpt> blocks now contain pass/fail information in the main browsers! https://github.com/tabatkins/bikeshed/commit/f07e1bf21590ce19405c02e483aa4520b4877ef4
wpt lines indicate when a test file contains multiple tests, and how many
If there's a WPT path prefix (or I can infer one), add the corresponding http://wpt.fyi link in the spec-metadata section up top
also add pass/fail data for all spec's tests combined to the spec-metadata section

And some other random stuff:

Stop doing the weird "implicitly call .format() on messages" and just use f-strings or explicit .format() everywhere https://github.com/tabatkins/bikeshed/commit/368df1cf2bb640348227ff65d56b6f17da1830c2
Update the dockerfile https://github.com/tabatkins/bikeshed/commit/24054d8e3fc4e2470137535ce54b9cd11d56242c
propdef tables now link their "Canonical Order" header https://github.com/tabatkins/bikeshed/commit/ed3425a59ec5f546f79b35df2d6e2d84fd3bf94a
bikeshed template now outputs a Status that actually works, so you can use its output immediately, as intended.

Version 3.3.1

adapt to the Process 2021 changes that got sprung on me without announcement

Version 3.3.2

I'd accidentally been omitting the wpt data files from the distributed version. They'll be as out of data by default as all the other built-in data files, but they should at least exist. Fixed now. https://github.com/tabatkins/bikeshed/commit/bbc364800e88c2472ca75ad7c5c8c3a09505a4b4

Version 3.3.3

remove some now-unused W3C NOTE statuses https://github.com/tabatkins/bikeshed/commit/6cf917509c94f769dea7d498f7fbe093c41ca809
Only set the LOGO macro if Logo metadata is actually set https://github.com/tabatkins/bikeshed/commit/31a2f03f4befb89325bebb9c5f25a84dce5fa119
Allow conditional logic to look at non-custom metadata too; combined with previous, you can now add a default logo if a spec doesn't set their own logo. https://github.com/tabatkins/bikeshed/commit/31a2f03f4befb89325bebb9c5f25a84dce5fa119

Version 3.3.4

CanIUse blocks are now closed by default, like MDN blocks https://github.com/tabatkins/bikeshed/commit/be0e7d0e15e69d1ce41dc87393a3a1d728d3f7fc
Fix update link for boilerplate files https://github.com/tabatkins/bikeshed/commit/a892fb19de40ebeaa698cff58dd55ed4f777dcc6
Actually clean up old boilerplate files that no longer exist https://github.com/tabatkins/bikeshed/commit/cace53f8cdd3fe04ceef2801e15a5f7fe8706630

Version 3.4.0

Add pngwg to W3C groups (I need to move this data out of this repo, too.....) https://github.com/tabatkins/bikeshed/commit/c9308f39fdde8a1360d92b3d108747fd91533198
New "direct" biblio style that still formats the link text as the shortname (to match the biblio entry), but skips the biblio and links straight to the document. https://github.com/tabatkins/bikeshed/commit/1f1661843554a272b4a14c35637caf3f2e16fa8a
Documented the W3C's spec-prod GH action, which makes it easy to auto-publish with Bikeshed
Disallow merged Privacy/Security sections, per new W3C rules https://github.com/tabatkins/bikeshed/commit/893894c7db84fc2f6610539350c69563ba4495df
When you've just got a few headings missing their ID, output them individually so they get line numbers https://github.com/tabatkins/bikeshed/commit/c29faa6f6b9210d0cf9d6f03202e009bb83257db
Document how to set "html metadata" (attributes on html, meta/link/style/script elements) https://github.com/tabatkins/bikeshed/commit/8eaccd9f127bedc5566dcac0c27aa196601adad7
Detect and scream when you're likely hitting the dumb years-old argparser bug about spaces in the values of unknown flags https://github.com/tabatkins/bikeshed/commit/beb1f2893fe20963f26d9285c8eed88b99b927c4
Strip the common WS prefix from fenced code blocks, same as I do for pre elements https://github.com/tabatkins/bikeshed/commit/53a81004f02671f93a75e16f7b9ad85a24fd8474
Add a new debug command to output all the metadata passed to the document, from all the possible sources https://github.com/tabatkins/bikeshed/commit/cd66b7b4622d0e5e396ef95308d80c7f8f74577e

Version 3.4.1

Previously, Bikeshed would helpfully not spam you with all the missing tests that matched your WPT Path Prefix if there were more than a handful, since there were legit reasons to have a bunch of untracked tests (tests not for your level, maybe you're in the middle of annotating, etc). Now that we have <wpt hidden> to do a well-targeted silencing when required, that's no longer a problem, so let'er rip. https://github.com/tabatkins/bikeshed/commit/f965859122fd22d04fb9094bf7c5b00b5ba48ca6

If you've only got empty/hidden wpt elements, Bikeshed no longer adds the JS, spec-metadata entries, etc. Style still comes thru so the blocks render, at least. https://github.com/tabatkins/bikeshed/commit/4d354f1e58e5760fb0f2db49a08bd005b0bdc6db

The legacy processor Bikeshed replaced handled links to properties and descriptors identically; 'font-family' would gladly link to the property or the @font-face descriptor, depending on what was in the spec. That never worked well in the first place (the Fonts spec would randomly link to each), and while Bikeshed could at least detect the issue and complain about it, it's annoying to deal with when properties are usually what you wanted to link to. It's gotten worse as we've added more descriptors whose names collide with properties, like 'width' or 'aspect-ratio'.
So, propdesc autolinks without an explicit for value are now always treated as property autolinks; 'width' will always link to the 'width' property, and never ask if you meant the 'width' MQ or CQ descriptor. You can still use the syntax with a for value, like '@media/width', to link to descriptors. This might cause some new link failures, but more likely it'll cause some existing link failures to go away and link correctly. https://github.com/tabatkins/bikeshed/commit/f9584d2c0f419a220c9d60f9998c3ed8d846496f

Version 3.5.0

Fixed the automatic indent-removal for pre blocks in some cases https://github.com/tabatkins/bikeshed/commit/bd9a15d0ee3f32ebd7e3d6a476c04482ec7fe15c
Added the [:http header:] autolink syntax
Added the "permission" definition type https://github.com/tabatkins/bikeshed/commit/f092c3aaae972eeb294877fb0bd5cca45537230d
Trust anchor-block entries, even if the spec you're linking to is marked as obsoleted in SpecRef https://github.com/tabatkins/bikeshed/commit/b1c6bfae8395782aa4ef1290724acc755171e41a
Allow div around dt/dd, including markdown-generated ones, since that's valid in HTML. Previously it would often kinda work by accident if you contorted your markup in a certain way, but it was real bad. https://github.com/tabatkins/bikeshed/commit/790e00888925ef861f2f4b1246c5f17736f7c090
Lots of adventures in beginning add typing information to Bikeshed. Long way to go yet.
Properly autolink the type signatures in argumentdef blocks. https://github.com/tabatkins/bikeshed/commit/ac0d42042966d025b5b8a547289665305eabfa53
Added a few W3C groups and statuses

Version 3.5.1

Added the fedidcg group

Version 3.5.2

Made section autolinks also trigger a biblio entry, which I believe is the last place that should be able to do so. Also localized the code that tracks this so all the entry points do the exact same thing; this means some of your biblio entries might change casing since they're consistent across all callsites now. There's still some mismatch between what specs I know about via biblio data and what specs I know about from definition data, which I know will cause at least a few instances where "the same" biblio entry shows up twice under slightly different names, but that's a separate issue that won't be fixed until I move Bikeshed's definitions entirely to Reffy. https://github.com/tabatkins/bikeshed/commit/fdd5936bf8dbfedd59b6f5837ea5f8a0e0db0752

Version 3.6

<div assert> now works, to get the same auto-generated ID as <assert> does, but for block-level. (<assert> turns itself into a <span> in the output.) (Thanks, @dj2!)
Fixed some new duplication of normative/informative refs caused by the section autolinks fixes from 3.5.2.

Version 3.7

Can now build multi-file specs directly from an (uncompressed) TAR file! This is worthless locally, but you can use this to send multi-file specs to the API server. (Thanks, @kainino0x!)

Been a while since my last batch of release notes!
Version 3.7.1

WPT tests mentioned multipled times in a spec now properly only count once for the test counts (https://github.com/tabatkins/bikeshed/pull/2304)
WPT summaries use the proper Stable channel browser logos (https://github.com/tabatkins/bikeshed/pull/2296)
Started some serious mypy-ification

Version 3.7.2

Fix a bug I caused while mypy-ing.
More mypy-ification.

Version 3.7.3

Fix a minor bug from an argument being removed in py 3.9.
More mypy-ification. (Seeing a trend? This continues until October.)

Version 3.7.4

Just mypy stuff. Unsure why I cut this version, honestly?

Version 3.7.5

Fix the merging of adjacent MDN blocks.
Fix caniuse and MDN darkmode styles.
Made the markdown em/strong replacers work better. They're still not right, but they're now less wrong.
Complain About: broken-links yes now has a timeout so it can't hang indefinitely.
Fixed a cache accidentally getting shared across documents, continually growing when you generate a bunch of specs (like bikeshed test does...)
Fixed how heading data is recognized from the data source, to better handle how ReSpec formats its markup.
FINISHED MYPY-IFICATION

Version 3.7.6

Properly add some new non-py files introduced by 3.7.5 to the release data.

Version 3.7.7

Fixed a spot where if you force-generate (so die() doesn't stop the program) it would end up with inconsistent state and cause a Python error anyway.

Version 3.8.0

Added simple def tables, formatted like propdef/etc but arbitrary keys
Added bikeshed update --force-manifest that forces it to do a manifest update even if the remote's date indicates your local data should be more recent.

Version 3.8.1

Fix anchor recognition, which was broken in 3.7.5 by the heading fix.

Version 3.8.2

Added a missing from __future__ import annotations that was causing a crash in older Python versions.
Only warn about missing WPT tests under your specified prefix once, rather than twice.

Version 3.9.0

Properly flag if your anchor-block refs have a local URL (which breaks other stuff anyway).
Fix a long-standing issue where section autolinks could generate a similar or duplicate biblio entry to what was already generated by definition autolinks.
Obsolete biblio links are now LINKERROR, not FATAL.
Moved the self-links from notes/issues/examples to avoid being cut off by their 'overflow' value.
HTTP Header autolinks now use the correct typography per Infra.
Added Complain About: mixed-indents yes to catch when you mix tabs and spaces in bad ways.

New big batch of release notes:
Version 3.10.0

Added explicit support for "Logical Property Group" in propdef blocks

Version 3.10.1

Biblio links now have the reference's title as their title (unless they're inline, since those already have the title as their text)
Better parsing for Markdown URL syntax. (Think it's still not perfect, but substantially improved wrt parsing the url portion.)
Fixed the bikeshed echidna --just-tar option to actually echo the TAR file, rather than whatever broken nonsense it had ended up doing.
Fixed a bug with negative ranges in the CSS <length [-100px, 100px]> syntax, and just switched to using hyphen-minus rather than the fancy math minus.

Version 3.11.0

Switched Bikeshed's ref database to using the W3C's WebRef service, rather than plinss's Shepherd service. Lots of commits related to this.
Note markers (the "Note:" bit) now have class=marker, as the docs said they should.

Version 3.11.1

Reworked the "unused var" error-checking so I could output line numbers, to help find the error.

Version 3.11.2 & 3.11.3

Bikeshed moved official ownership! Now a project under the Specification Editors CG in the W3C, at https://github.com/speced/bikeshed.

Version 3.11.4

After some poking at WebRef to get the data complete, Bikeshed no longer relies on Shepherd at all.
Put a really cute little progress bar on both the manual update info, and test running.

Version 3.11.5

Fixed the "mixed indentation" lint to properly allow tabs followed by spaces. (Spoilers: it's still broken at this point.)
Added the first part of my new bespoke HTML parser.
Fiddled with the dfn panel generation/positioning for better a11y.

Version 3.11.6

Fixed the "mixed indentation" lint correctly.
Try to infer the indent from source analysis, rather than just looking at the first indented line.

Version 3.11.7

Fiddle with ID generation for links that dfn panels need to link to, to make them more likely to be unique.

Version 3.11.8

Fix how I package bikeshed for release, so I'll stop forgetting to include new .css and .js files when I add them.

Version 3.11.9

Fixed a filepath.

Version 3.11.10

Removed a good chunk of the ARIA stuff I tried to add, since it technically violated the ARIA spec (even tho I think it was right). Grumble, grumble.

Version 3.11.11

Unify a lot of the CanIUse/MDN panel code, particularly positioning. Switch them from doing some funky abspos-with-static-position stuff to being positioned purely with JS, since they can trivially overlap otherwise.
Specs marked as "fork" in WebRef are no longer included in the db.
A bunch of fiddling with the update code to untangle the old mess of transforms needed for mixing the Shepherd and WebRef sources. Since it's all WebRef now I can make it much simpler.

Version 3.11.12

Accidental rerelease, lol

Version 3.11.13

Include .bsfont files in the build too. Surprised this is the first time someone's run into this issue!

Version 3.11.14

Preserve the start-tag's attributes when handling all the various datablocks (propdef, railroad, include, etc).
Move the semver file into the bikeshed folder so it's actually installed by pip. Turns out the top-level files aren't!

Version 3.11.15

Nothing, just didn't notice the semver got bumped again while I was fiddling with the release script.

Version 3.11.16

Since 3.11.14 started using the new bespoke HTML parser, it can accidentally surface some HTML mistakes that were previously silently accepted. The error messages weren't showing the right line tho - now fixed.

Version 3.11.17
Turns out using just a little of a new HTML parser causes problems when my old hacky line-based code is, well, doing things line-by-line, and thus only feeding the parser part of a tag when a tag is split across multiple lines. So now I just use the HTML parser for the entire pre-Markdown parsing pipeline. (Then Markdown runs, generates some HTML, and feeds its result straight to the lxml parser. Both of these will be rewritten in time as well.)
It looks like this doesn't cause any issues with the testsuite, and hopefully should resolve the spurious fatal errors that 3.11.16 was throwing. Lmk if you see any issues!

Thanks Tab for the quick response and the postmortem. I'm really excited about work on tracking build messages, and also only making changes as PRs on GitHub. The way in which ~half of the commits on https://github.com/speced/bikeshed/commits/main have red Xs next to them has made me very nervous about using Bikeshed in the past, and moving to a PRs-with-CI-checks model would be a huge boost to my confidence in the software. Especially once those CI checks include build messages.

Oh. That's disappointing. I wish you would treat main with the same care as you treat releases, and used CI to validate your changes, like modern software best practice requires (e.g. on the Chromium project we both contribute to).
Now that Bikeshed is part of SpecEd, is there a way to ask "SpecEd" for that sort of working mode?

I wish you would treat main with the same care as you treat releases, and used CI to validate your changes, like modern software best practice requires (e.g. on the Chromium project we both contribute to).

Why? This isn't a rhetorical question - what is the reasoning behind you wanting this?
Chromium is a massive multi-contributor project; it needs a core that is stable/correct for all the contributors to work from. Bikeshed is largely a single-contributor (me) project, and I don't believe my working mode is what's stopping more contributions. Bureaucracy exists for a good reason, but it's also a significant drag on its host; this is more than worthwhile when it's cutting thru the N^2 growth of personal connections between contributors, but not when that N is very low (again, approximately 1 here).
The group of people that do need stability in reference to Bikeshed are, currently, just the users, and they're served well by my release process. You are also in that group; as WHATWG uses the API server, which now follows releases rather than main, you're exposed solely to what I do in releases. What happens in main is irrelevant in practice for you.

Now that Bikeshed is part of SpecEd, is there a way to ask "SpecEd" for that sort of working mode?

No. I moved Bikeshed to SpecEd for continuity reasons; my getting hit by a bus will no longer mean that the development has to fork to continue. I did not move it to enable non-contributors to impose currently-unneeded bureaucracy on the project.

It's sad to me that you see proper software engineering practices (which are used by teams of all sizes, including one) as bureaucracy. If there's such an ideological gap at this point, I don't think we'll be able to make further progress through discussion, at least not until more incidents of this sort (or others we've seen throughout Bikeshed's history) accumulate.

I wonder if there is just a misunderstanding going on here.  Given my limited knowledge of git, I may be missing something, but a few things are clear to me, and as one of the contributors of a small fraction of changes to Bikeshed, I may have a few useful insights.
One thing we should be able to agree on is that the error status of commits should be considered totally irrelevant as long as the last commit before squashing and merging is "green".  The commits are just intermediate states that are steps along the path toward a final PR submission, which is true both for main and any branches.   In fact, I find the extra steps of staging changes, then committing changes, and then syncing changes, almost entirely annoyingly extraneous.
Doing independent work on branches separate from origin/main, such that once we merge a PR from any branch into main, it will typically require only a single commit that very likely will have no errors, is yet another step that I am happy to avoid, as long as we can avoid problems.   I believe, with small teams, this is common practice, and it works fine as long as there are sufficient tests to ensure PRs won't cause unexpected problems.   I don't know what the dividing line between small and large teams is, but it probably depends a lot on the nature of the project as well, and how the work is typically distributed.
The Bikeshed repo already does have a moderately large test suite that is applied after each commit.  Running these same tests locally, before commit, is also possible, but not essential to ensure a reasonable level of integrity.   Sharing intermediate state of a draft PR with co-workers by way of committing changes that might still be very incomplete and full of errors is a very useful technique which we should not sacrifice.
Whether origin/main itself with all the current accumulation of PRs has errors is another question.  I would expect that we should never merge in PRs that result in known errors, unless we have high confidence that they are spurious, or that we will quickly fix the errors in a subsequent PR.   Then the next boundary condition happens when origin/main is released to the public, which should be only happen once more rigorous testing and sufficient reflection results in even higher confidence that everything should be OK.
So, is the discussion about whether PRs to origin/main should ever result in known errors, or whether we have sufficient tests to have confidence about whether known errors are relevant, or something else?

@domenic I'm pretty sad to see this level of condescension, yes. I asked specific questions and gave specific reasoning for my decisions, and I'm getting back generic platitudes about "good software engineering", implying strongly that I am being a bad software engineer by not immediately adopting your suggestions.
Bureaucracy is not a bad word: it is both an essential part of any organization as it grows (to linearize communication pathways as the network of participants grows), and a significant cost to all participants (as they have to service the bureaucracy rather than working directly on the task or with each other). Adding bureaucracy needs justification.

Whether origin/main itself with all the current accumulation of PRs has errors is another question. I would expect that we should never merge in PRs that result in known errors, unless we have high confidence that they are spurious, or that we will quickly fix the errors in a subsequent PR. Then the next boundary condition happens when origin/main is released to the public, which should only happen once more rigorous testing and sufficient reflection result in even higher confidence that everything should be OK.

Right. Bikeshed started as a single-developer project (with frequent but relatively minor contributions from others) with a small community of users (the CSSWG). At that time, working directly in main, and serving directly from main, made sense; the community was small and close-knit, so problems could be immediately communicated and fixed. Keeping main in a working condition was important, but short-term failures, quickly detected and fixed, were okay. Branches were used when doing larger projects that needed the checkpointing of commits, but might leave the codebase in a broken state until it's finished.
Bikeshed has grown since then. Currently the developer situation is still fairly similar - it's mostly just me, with occasional contributions from others. (In fact, spot contributions have mostly dried up as it's become larger and more complex.) So working in main, with occasional branches when necessary, is still pretty reasonable.
But the community has massively expanded, to encompass most of the W3C and a large and diverse set of disparate users elsewhere. I can no longer count on people reporting issues to me; it's more likely that they work around the issues instead. (I do still get plenty of bug reports, which I of course love.) And due to this size, it's more likely that every exposed version is used by a non-trivial number of people, so short-lived failures can still cause significant pain. Thus moving to a release model made a lot of sense, and this has been largely successful. This also means that users are insulated from whatever happens before the point of "cutting a release".
If Bikeshed ever starts getting more community contributions, more stringently maintaining a known-good main would make sense, so short-lived failures accidentally introduced by one dev don't overly affect the other devs. Until that happens (and I'm not confident it ever will), the current main shepherding continues to work fine. We could also change it if we believe that the current main shepherding is preventing people from feeling comfortable contributing, but I don't believe this is the case currently.

Version 3.11.22

Significant refactoring of the "dfn panels" that show up on definitions and list all the links in the document. To reduce the amount of repetitive HTML sent down the wire, these are now sent in a reduced JSON form and constructed in JS on load.

Added a new Ignore MDN Failures metadata, allowing you to silence an MDN failure (to deal with transient errors due to something moving between specs and MDN temporarily being wrong about where a feature lives).

You can use <wpt skip-existence-check> to make the WPT block, well, skip the existence check. This lets you use URLs that aren't in WPT at all, or aren't there yet, and still get a similar-looking test block. (No pass/fail data or the helper links like source vs live, but otherwise same as normal.)

Version 3.11.23

Fixed a bug in highlighting, where sometimes a <pre class=include-code> would drop the last line of the include. (#2521)

Slightly improved how I auto-generate IDs for some links (that need to be linked to by dfn panels, etc.) If you were depending on those auto-genned IDs, uh, they're different now. (#2531)

Version 3.12.0

Refactored all of my darkmode handling to work properly. There's a new Darkmode metadata you can use to turn off Bikeshed's darkmode styles.

Version 3.12.1

Removed some final remnants of the old CSSWG testsuite data. If you don't know what that is, don't worry it didn't affect you.

Version 3.13.0

Removed the ABSTRACTATTR macro, now that nobody consumes it. (It was the same as the ABSTRACT macro, but escaped to be suitable for use in an attribute value. But ABSTRACT is HTML content so it was weird to do that in the first place.) This almost certainly doesn't affect you either.

Removed flake8 from my linting pipeline, added ruff to replace it, and turned on a FUCKTON of lints. It can't quite replace pylint yet, but it's close, and it's SO FAST.

If you do something that makes an invalid spec (like invoking Bikeshed without an input file, with no .bs file in the current directory), I now properly catch that and fail gracefully from several commands rather than dying with a Python stacktrace.

Did a bunch of refactoring of the Install/Use section of the docs to emphasize using pipx to install and manage Bikeshed, as a much easier and safer install tool, and to expand some examples of how to use Bikeshed within GitHub CI.

Bikeshed now checks if your datafiles are relatively old and automatically attempts to update them, so you don't need to run bikeshed update yourself. I did a lot of refactoring in this code and it seems to be great, but please let me know if there are any issues.

Version 3.14.0
Let's try that HTML parser rewrite again! Coming at it more gradually now; I do one early pass over the document with the new parser and then just reserialize back to a string. I haven't yet replaced the datablock, markdown, or shorthand parsing, and I still pass it to the pre-existing HTML parser to actually build a tree, so mostly this is just some extra work being done, but those'll all be absorbed into this work in later phases.
As I say in https://github.com/speced/bikeshed/pull/2602, this brings a few benefits immediately:

Detects some markup mistakes, like duplicated attributes.
Correctly adds line numbers to everything in your source. (Some elements coming from metadata or datablocks still won't have correct line numbers.)
Handles markdown code spans, code blocks, CSS <<type>> autolinks, and CSS ''maybe'' autolinks correctly, in the parser, rather than hackily via a regex.

It then still runs the datablock, markdown, and finally the existing HTML parser over the spec, so this is probably slightly slower at the moment, but those will be eaten by the parser in later phases.
Known issues with existing specs' markup:
If you were working around the hacky ` parsing by using \` inside of a code block
(which shouldn't have any parsing done inside)
it no longer does any parsing inside.
Fix: Remove the spare \ so you just have valid JS again.
If you weren't working around this your spec was probably broken,
and now it's fixed!
The HTML parser runs before the Markdown parser right now
(fully integrating the two together is the next project),
so a tag broken across a line inside a blockquote
will parse incorrectly
(it's closed prematurely by the blockquote's > at the start of the next line)
Fix: just put the whole tag on one line for now.
Previously, ''<foo>'' would make a maybe autolink to <foo> as a value.
Now it's equivalent to <css>&lt;foo></css>,
which is broken,
but arguably it was always broken in the first place.
Fix: change to ''<foo>''.
The Markdown behavior of "if you have spaces at both the start and end of a code span, remove one from each side" is now properly implemented. A few specs relied on it removing any amount of any whitespace, so now there's an extra space sometimes if you did a linebreak inside your code span for some reason.
Fix: Put the code span all on one line, or at least don't linebreak between the end of the content and the closing ticks.
(The serializer still collapses starting/ending whitespace down to a single character to make the content look better, so that might still be doing more stripping than you want too.)

A few small updates in the last few weeks.
Version 3.14.1

The AB is now a W3C group (I really need to move this data to bikeshed-data rather than in the Python...)
(temporarily) allowed CR as whitespace, to fix a confusing parse error that some people were getting.

Version 3.14.2

Made = in unquoted attribute values not an HTML parse error, so you can still have unquoted URLs with query strings in your attributes. (This'll be partially reverted in a future version, as the parse error apparently legitimately catches a lot of problems in the wild where people accidentally omit the space between two unquoted attributes, but I'll keep the exception for attributes known to contain URLs, like href and src.)

Version 3.14.3

reverted the CR change from 3.14.1, instead properly normalized linebreaks when the source file comes from a URL. Turns out requests doesn't do this for you, while the rest of Python file loading does.

Version 3.14.4

Added a Die On metadata, paralleling the --die-on command-line flag, that controls what level of error message results in the spec failing to build entirely. No change to existing documents (it still defaults to "fatal"), and the command-line flag still overrides anything coming from metadata.
Allowed W3C Community Groups to use the w3c/UD status, since it's an unofficial status anyway, and useful to distinguish from their "real" draft statuses.

Version 3.14.5

I now finally track console output as part of the testsuite as well. Previously I just monitored the actual spec output, but new fatal errors could show up without changing the output (and even changes to warnings could break builds that were using --die-on=warning to ensure a clean build). Shouldn't run into surprises like that anymore.
When using <pre class=simpledef>, I no longer automatically sentence-case the keys, so you can do things like {{someMethod()}}: describing the method and the link will no longer get broken.

Version 4.0.0
Woo, major version bump! Content-wise this isn't a break-worthy update, but Bikeshed has officially deprecated support for Python 3.7 (and 3.8), and now requires a minimum version of 3.9. As far as I can tell, this is the highest widely-supported version among default installs now; the old OSes that bundled 3.7 by default are all now out of long-term support.

The link-checking lint now properly handles a timeout.
If you're building a spec from within a github repo, the commit is now recorded in <meta name=revision>, to accord with the registered meta name for this purpose.
Some minor fixed to how dfn panels work.

Clicking the "self-link" in the panel no longer triggers it to move down to the lower left corner; that only happens if you click one of the references to the dfn.
Dfn panels no longer get clipped by overflow on ancestors of the dfn. (This did require switching to positioning them more manually with JS, rather than being able to rely on CSS's "static position" concept; please let me know if anything looks wrong.)
Dfn panels now more intelligently avoid overflowing the screen, sliding nicely away from the edge to stay visible.

In addition to dfn panels, we now have link panels, which show on hover and fade away more eagerly. They give a few useful bits of information about the link now, and will be developed more in the future.
Added a new --die-when command-line argument, letting you toggle between a fatal error stopping Bikeshed immediately, or just stopping it at the end from actually producing output. Defaults to "late" now (continues processing, only dies at the end), so you can see all your fatal errors at once. You can pass --die-when=early if you have too many errors and want to fix them one-by-one.
Both --die-on and --die-when can now be specified in your metadata (including in your group's defaults), as Die On and Die When, taking the same values as the command-line args.
The manifest for Bikeshed's data files is now written in KDL rather than a bespoke format, so it should be more easily changeable in the future. (This shouldn't affect your authoring experience at all.)
This existed before, but it's now documented: if, for whatever reason, you need to skip Bikeshed's auto-update check it does at startup to ensure its data files are up-to-date (for example, if you're on a plane and dont' want to wait for the network to time out every time), you can pass --no-update on the command line.
The [TITLE] macro, used to pipe the document's title into the <title> element, now omits markup in your Title metadata and just contains text. (<title> is specially parsed in HTML, similar to <xmp>.) This means you don't necessarily need to write both Title and H1 metadata if you want to put some markup into your document's <h1>. (But if you're using markup with semantic visuals, like <sup> or <sub>, you probably do still want to do something different there.) This ended up fixing accidental markup getting spewed into the document title for several specs in my testsuite.
Syntax highlighting no longer strips whitespace from the start and end of the block. Spot-checking a few places where this caused a minor output difference, it doesn't look like it actually causes a visual difference. But this does fix a bug that a few specs hit when combining highlighting with existing markup that subtly corrupted the text.
If you had <pre highlight=foo><code>...</code></pre>, previously it would get double highlighted. (Shouldn't have been visible, given the highlight styling most people are using, but it was silly verbose markup.) No more!
Fixed a crash bug if you tried to use an HTML character reference that either expanded into two codepoints or a single astral codepoint. (Nobody hit that in my testsuite, but still.)

Most of my time was spent on making Bikeshed's new HTML parser more powerful and more correct (mostly in https://github.com/speced/bikeshed/commit/5c6f7af73bbe345046023dc3c6ba4704044ff07a). This shouldn't have any big effect on you (some caveats, below), but every step forward I make here makes me so much happier.

All of the early text-munging I previously did before running markdown/html parsers is now moved into the HTML parser: macros, curly apostrophes, and line-ending em dashes. This means Bikeshed will no longer accidentally modify things inside of script/style/xmp elements, markdown code spans or blocks, or Bikeshed "datablocks" (the <pre class=foo> things that are specially handled).

A few specs in my testsuite had manually corrected for this, using Markdown escapes so their JS template strings weren't detected as Markdown code spans. These'll need to be removed; the \ is now output as part of your spec. Sorry. (However, more specs hadn't corrected for it and just had broken output; they're now automatically fixed.)
Macros are now valid only (a) in text, or (b) in attribute contents. Nothing in the testsuite used them anywhere else, so this should be fine, but FYI.
Macros can now correctly handle having more macros in their content. I'll catch accidentally-recursive macros so you won't hang Bikeshed with infinite replacements, tho.

Several metadata lines that are meant to contain HTML are now fed to Bikeshed's new HTML parser as well, so you'll catch errors there too.
So are your boilerplate files (so the new macro parser can do its job). Again, this might catch some HTML errors in your boilerplate; open a PR in speced/bikeshed-boilerplate if
A stupid amount of fiddly work went into making line numbers in error messages more common and more useful. Line numbers from things outside your core document now give their context, so you won't be confused looking at line 20 of your spec when it's actually an error at line 20 of your header.include file, etc.
I also fixed a bunch of off-by-one errors in line numbering. If you still see any errors that misattribute their line number, please let me know.

Exception: line numbers like "Line ~20" (with the tilde) still happen for the remaining linking shorthands that don't know their original line number; they're instead reporting the line number of the nearest construct (HTML element or Markdown block) that does know its line number. If that's incorrect, tho, let me know.
Exception: If an error like the previous bullet point occurs in top-level raw text that doesn't get wrapped in a Markdown paragraph, it might report the line number of the wrapper element coming from your header.include. This sucks, I know.
Both of these will be fixed in an upcoming version before EOY, when I migrate all the stuff that gets parsed after Markdown/HTML parsing into the bespoke parser, so they'll know what their actual source line number is.

HTML comments are handled slightly differently internally now; this should generally be undetectable (or work better!) except for perhaps some trailing whitespace appearing where it wasn't before (but was present in your markup). Please let me know if something looks to have messed up, tho.

I did a lot of careful test review to make sure things are as correct as possible. Aside from the bits I listed above, and the possibility of some new markup errors being flagged,

Version 4.0.1

Tiny fix - I had some invalid CSS in a new feature that was causing validators to complain.

Version 4.0.2

Fixed some cases where an <l> element wasn't turned into a valid HTML element.

Version 4.0.3

Totally refactored my JS/CSS inclusion code. Just an internal thing, tho scripts/styles will move around a bit since they're now alphabetized by their boilerplate name, and the couple that host JSON data changed how they store it.
Rewrote several of the JS scripts that were unintentionally spending a lot of computation at page load. For large specs like DOM, this changes ~2s of computation to ~100ms.

Neither of these should actually affect specs in a user-observable fashion; let me know if anything seems to be newly wrong.

Version 4.1.0
Several miscellaneous fixes; I wanna get these out before I dive back into the parser.

Now that dfnpanels contain linking guidance, they're useful on all dfns, so Bikeshed now generates them for all dfns. (Previously, since they only contained links to where they were referenced, they were only generated for dfns that had local references.)
The pass/fail colors for MDN panels was accidentally still inline, so they've been pulled out into a color var so they can be darkmoded.
If you write <dfn><<length [0, 10px]>></dfn> (defining any type shorthand with a range), Bikeshed will now auto-infer that it is actually a value definition, rather than a type definition. This might change some IDs, if your dfns weren't tagged before and you were relying on auto-detection.
I now properly handle Python errors raised during metadata parsing (rather than just exploding).
When you turn off (with the Boilerplate metadata) a script or style with an associated style/script, I now properly omit the associated stuff too, without you having to manually turn them off.
Updated the WebIDL Parser version, to capture some recent changes.
Bikeshed's auto-update feature that keeps your datafiles up-to-date now does a fast check for internet access, so you're not stuck waiting for a timeout when you're, say, on an airplane.
Also, auto-update will no longer fall back to manual update if the manifest update fails; it's supposed to be a fast best-effort thing, and manual updating is SLOWWWWWW.
Also, if manual updating throws an error, I now properly handle that.
The Big Text functionality invoked by bikeshed source is completely rewritten.

Most importantly, it now keeps the original comment text in the document, so you can just fiddle with it inline and re-run the command, rather than having to delete the generated comment and add back a new <!-- Big Text: foo --> comment.
Created a second, narrower font file, too, and switched to it by default. You can fit more letters on screen now!
Font files are now written in KDL, rather than a bespoke format.

Version 4.1.3

Sorted the WPT path fragments from the previous version, so the output is stable rather than reliant on set iteration order.
Removed the code in dfn popups that prevented the page from scrolling when the target was already somewhere on screen, as it also prevented the hash from updating.
Firefox has a buggy implementation of .offsetTop on some internal table elements, and that made dfn/link popups misalign when their anchor was inside of a table with a caption. Switched to using getBoundingClientRect() to calculate their positions instead, which consistently works everywhere.

Version 4.1.4

The --die-on and --die-when flags are now properly piped into the metadata infrastructure, so they'll win over less powerful Die On/When metadata as they were intended to.
HTML comments in def blocks are now properly ignored, as they were before the parsing switchover when I was unsafely stripping them from everywhere.

Version 4.1.7 & 4.1.8
(4.1.7 was an accidental no-op release.) Tiny update!

Added htmlwg as a recognized W3C Group
Updated widlparser

Whoops, left a few version off the changelist. They're all minor except the last.
Version 4.1.9

Just adding a new WG (SOLID CG) to the data files.

Version 4.1.10

Made the var-highlighting colors (the backgrounds that show on up <var>s inside of <div algorithm> blocks when you click the vars) darkmode-aware.

Version 4.1.11

Made the default tracking-vector image darkmode-aware.

Version 4.1.12

Just adding a new group (W3T) to the datafiles.

Version 4.2.0

Moved the data about what groups and statuses exist, which statuses a group is allowed to use, etc. over to a datafile in the bikeshed-boilerplate repo. Previously, updating this requiring rolling a new Bikeshed version; now it can be updated alongside new boilerplates being added! No more silly updates like 4.1.9 and 4.1.12.

If you're missing some IDs that the MDN data expects to be present in your spec, the error message is a little better now.

Fixed a weird corner case: as long as there's only a single overload for the method, you can always autolink a method without passing any args: {{Foo/bar()}} links to the bar() method, regardless of how many args bar() actually takes.
Because IDL methods and attributes occupy the same namespace, you were also allowed to autolink to methods without using parens at all, like {{Foo/bar}} to link to the Foo.bar() method. However, due to some slight mismatches in how two different systems interfaced, this only worked if the method could be called without arguments. If there were required arguments, it didn't work; but {{Foo/bar()}} (parens, no args) still worked fine.
This is fixed now, tho there are a few specs in the end-to-end testing database which now have ambiguous autolinks as a result. It's likely a few specs in the wild might run into the problem as well.

Fixed a crash bug that could occur while I was figuring out your spec's indent level, if the spec contained at least 50 space-indented lines but they were all indented with only a single space.

Version 4.2.1

Fixed a couple of W3C URLs https://github.com/speced/bikeshed/commit/61fea1be4463fd1ad9182d767287ecf7d6044fc6

Made bikeshed spec pay attention to --print=json (previously, only bikeshed refs used it), and document that value. https://github.com/speced/bikeshed/commit/296e6fd70c6cb8c8a7c774cc980601c21b793e45

Version 4.2.2

Fixes the parser to allow for <<foo [<<bar>>]>> shorthands to be parsed,
now that that's an allowed syntax for CSS grammars.

Version 4.2.3

Allow <<foo []>> (with an empty arg).

Version 4.2.4

Didn't realize that argparse (the cli library I use) doesn't correctly handle the same option name being used both at the top-level and in a subparser, so moved the --no-update top-level option to a new internal name. (No effect on user-facing code, except that bikeshed --no-update spec and bikeshed update --skip-manifest both correctly work now`.)
Fixed #861, so refs with "significant" casing get that casing preserved when they're printed in indexes/etc. (Before, "dfn" type refs were always lowercased, so for example "ECMAScript" would print as "ecmascript" in the indexes.) There's some minor heuristics involved so sentence-starting refs don't preserve their casing accidentally.

Version 4.2.5 - 4.2.7
Insignificant version bumps, just me trying to get py.typed included, so mypy knows about Bikeshed's types.
Version 4.2.8

Bumped a lot of dependencies.
Finally fixed the NodeJS favicon used by the CanIUse panels.


node version 0.10.x vs. new

I'm not an expert on this, but I've just seen other projects recommending to use only Node 0.10.x for tilelive-vector, and it's also the required engine in it's package.json:
https://github.com/mapbox/tilelive-vector/blob/master/package.json
In case there are possible bugs with tilelive-vector, it might be because of node version, just to keep in mind. One related issue: https://github.com/mapbox/tilelive-vector/issues/103
// sorry if everything is working fine with Node 5.x, I just wanted to make a note about possible bugs.

I'm not an expert on this, but I've just seen other projects recommending to use only Node 0.10.x for tilelive-vector, and it's also the required engine in it's package.json:
https://github.com/mapbox/tilelive-vector/blob/master/package.json

Great feedback. This is stuff we would never notice. Thanks.
Our build suddenly started breaking with node 0.10.x (even though we fixed the npm versions) #139 that's why it thankfully got fixed in #160.
I want to keep this issue open as a reminder for some time when bugs and weird things start happening we have a clue why.

@lukasmartinelli #160 changed both the package versions and the node version. I'd guess it was the package versions which fixed the bug, and it'd work with node 0.10 as well.
node-mapnik says this on the homepage:
depends: Node v0.10.x or v0.12.x (v0.12.x support requires node-mapnik >= v3.1.6)
however they do provide "matrix" builds (that's wheel / bundle for node AFAIK) for node 0.10, 4, 5
https://github.com/mapnik/node-mapnik/blob/8faf1774e799e43d4becef37797cc4632266328c/.travis.yml#L29
Afaik, mapnik is a pain to compile, and sticking with the matrix builds is a good idea (afaik we are getting those at the moment).
Mapbox seems to be using node 0.10 in production, as it seems from their travis.yml files:
https://github.com/mapnik/node-mapnik/blob/master/.travis.yml
https://github.com/mapbox/node-mbtiles/blob/master/.travis.yml
https://github.com/mapbox/tilelive/blob/master/.travis.yml
https://github.com/mapbox/tilelive-vector/blob/master/.travis.yml
https://github.com/mapbox/tilelive-bridge/blob/master/.travis.yml
https://github.com/mapbox/tilelive-mapnik/blob/master/.travis.yml

Thanks again @hyperknot for the detailed research.
Let's roll back to v0.10 again and try get a working set of dependencies based on
<EMAIL_ADDRESS>

I updated all Dockerfiles to node 0.10 and bumped the packages in this PR, waiting to see if build succeeds:
https://github.com/osm2vectortiles/osm2vectortiles/pull/168


quick fix to handle BigNumbers array as argument of the event log

expected:
as [ BigNumber { _hex: '0x01f4' }, BigNumber { _hex: '0x01f4' } ] equals [ BigNumber { _hex: '0x01f4' }, BigNumber { _hex: '0x01f4' } ] - it passes the test
actual:
AssertionError: expected [ Array(2) ] to equal [ Array(2) ]
    at assertArgsArraysEqual (src/test/productAssetIdentity.spec.ts:65:51)
    at derivedPromise.promise.then (src/test/productAssetIdentity.spec.ts:71:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)

switching to deep.equal also doesn't solve the issue...
quick and dirty fix is to stringify the actualArgs and expectedArgs values of every argument within withArgs method.
this makes however you equal overwrites to handle BigNumbers useless...
as an alternative if the value is an array we can compare each value separately

Are you using expect(arr1).to.deep.eq(arr2)?

The problem is within .to.emit().withArgs() method and precisely assertArgsArraysEqual helper function.
(In assertArgsArraysEqual)

switching to deep.equal also doesn't solve the issue...

The issue is when you have as one of the event arguments a big number array. I updated the initial comment for clarity.

@bytniak Awesome work! 👍👍👍
Thank you! ❤❤❤
Published in 2.1.2

Thx! @marekkirejczyk.


New CLI for triggers create/delete/update/list and new IT tests

Issue Ref: [Issue number related to this PR or None]
Adding new CLI and integratio tests. Will mark for review once IT tests are stabilized in the CI.
Description:
[PR Description]
TODOs:

[ ] Ready to review
[ ] Automated Tests
[ ] Docs

Closing this PR in favour of #643 opened against master.


Stack and queue

[x] - Node Test: Node class created.
Stack Tests
[x] - Can successfully push onto a stack
[x] - Can successfully push multiple values onto a stack
[x] - Can successfully pop off the stack
[x] - Can successfully empty a stack after multiple pops
[x] - Can successfully peek the next item on the stack
[x] - Can successfully instantiate an empty stack
[x] - Calling pop or peek on empty stack raises exception
Queue Tests
[x] - Can successfully enqueue into a queue
[x] - Can successfully enqueue multiple values into a queue
[x] - Can successfully dequeue out of a queue the expected value
[x] - Can successfully peek into a queue, seeing the expected value
[x] - Can successfully empty a queue after multiple dequeues
[x] - Can successfully instantiate an empty queue
[x] - Calling dequeue or peek on empty queue raises exception


fixes bug 1295593 - Move "Tags" tab into "Details" tab

Coverage remained the same at 86.083% when pulling 213c524d14c790b95b3d07b2232fed86c6df479d on peterbe:bug-1295593-move-tags-tab-into-details-tab into be864ca2c0b16d9888cda13636ada100409b2d0e on mozilla:master.


Added Subject (ClaimsPrincipal) to refreshtoken store

Hi @jageall ,
Is there a missing Serializer for ClaimsPrincipal when it comes to the subject property of RefreshToken?
Some users experienced errors with the mongodb backing stores after upgrading idsrv to 2.6.0 , where the Subject property of RefreshToken is in use.
https://github.com/IdentityServer/IdentityServer3/issues/3470

Thanks @johnkors . I'll get this merged in, double check there is nothing else missing and push a new package within the next few hours