Making up fake email addresses that use real domain names is a bad idea and in my experience also extremely common. To help people avoid that situation, here is a list of all the domain names that I know of that are reserved explicitly for purposes like testing and documentation.
Reserved by RFC2606/RFC6761.
This works around an issue where using Istanbul with the noop instrumenter means it will try to parse your code with a hard-coded Babel config that may not work (especially if the code it's trying to parse is TypeScript).
This kludges the problem away by using patch-package in a post-install script to patch istanbul-lib-instrument to look for an environment variable pointing to your Babel config file, and a one-line patch to nyc to make it pass the filename when calling the patched functions in istanbul-lib-instrment (otherwise it will fail if your babel config includes overrides).
To use this, setup patch-package as shown in their README, then make a patches directory in your repo and drop these two patch files into it. Then just running yarn (or npm install) should be enough to do the patching. Then you just have to make sure that $ISTANBUL_BABEL_CONFIG is set to the path to your babel confi
The [2022.9][release] release of [Home Assistant][hass] add a much-anticipated integration for doing firmware updates on z-wave devices. I immediately rushed to update the 36 devices it said there were updates available for. Then I woke up the next morning to find it telling me about updates for 35 of those devices...
It's a brand new feature, so I'm not too worried about it being a little rough around the edges at the moment, for now here is what I've found:
First off, let me say that 1password is a great tool that I use every single day.
That being said, however, as a web developer it has one very obnoxious problem that they are unwilling to fix: There is no way for a developer to indicate that a field that 1password thinks should be filled from it's vault should in fact not prompt the user to autofill it.
Some examples of completely valid use cases made absurdly painful by this refusal include:
I wanted to be able to put the Consul UI behind a reverse proxy, and be able to access it as https://example.com/consul, but it doesn't seem to support that out of the box.
According to hashicorp/consul#14342 it's supportd and you can set a variable to tell the UI what prefix to add to the front of API requests, but after a couple of days of trying I could not figure out how to set that variable (and comments on the PR suggest that nobody else has figured it out either, and Hashicorp hasn't responded to any of those).
I did manage to get it working, but it needed a little kludge. Since I couldn't figure out how to get Consul to set the right variable in the UI, I made Nginx do it instead.
This is the configuration I ended up with. As a bonus this config also includes a map that makes the UI default to read-only even if the UI is running on the consul servers.
References: