Use package.json engines version?

Run nvm use will read local package.json's engines.node and change version accordingly.
Or anyway that auto switch the version.

Hmm - engines.node is only meant to be advisory, and no part of the node ecosystem uses it for any other purpose. For example, if a package specifies "0.8" that doesn't mean it won't work on iojs or 0.12 - it might be problematic to default the user to 0.8 just because the author hadn't updated their package.json.
I could definitely add this as an alternative, when .npmrc wasn't available - I'm just not convinced it would be a good thing. Also, the engines field can specify semver ranges - so I'd need to use semver to resolve that between the available node versions - which is a dependency that requires node in software that doesn't have node as a dependency.

NPM treats engines.node as advisory, but that's not the only way to use package.json. It's actually very convenient when everyone on the team, the CI server, and production servers all pick the same version, based on package.json. And a huge time saved when shuffling between multiple projects (consulting, microservices, migration, etc).
So it would be of great help if nvm could pick up on the current project's specific choice of iojs/Node.

@assaf it already can! Just put a .nvmrc file in your project repo, and do a bare nvm install or nvm use in the project directory.

How do you tell .nvmrc to pick the version specified in package.son?

That's not what I meant - I meant you just manually put a version in that file and commit that to the repo.

That's not what I was asking for. Having multiple files that specify which version of iojs/Node is in use, just means more things breaking because "works on my machine". Common sense is to keep the project DRY and have a single authoritative specification of the version in use.

Right, I agree with that. The problem is that node.engines in package.json specifies the minimum version a module works with - ie, most of mine say 0.4, but I wouldn't want nvm to use 0.4 by default. By contrast, .nvmrc specifies the version I want to use it with, which is the maximum version it works with - iojs or stable for most of mine.

If you don't like this feature don't use it. I'd like to have such a feature that I will then choose to use for my projects.

"if you don't like it then don't use it" is not really a good justification for adding any feature to any project. It's nice that you want it, and thanks for offering your thoughts, but:

I don't think the feature makes sense semantically - in other words, that the package.json "minimum supported version range" field makes sense as a "run it under this one single version of node/io.js"
Parsing JSON from the shell is prohibitively complex - we can't use any npm modules and would have to use a technique that worked in bash, dash, ksh, and zsh. Can you suggest one?
The semver range issue I mentioned above.

In other words, even if I thought this was a good feature on its face, there's just no way it's practical, so it simply can't happen.
I'm happy to review a PR in the future if someone can come up with a simple way to achieve it, but I remain opposed on the semantic appropriateness of this feature and would need to be convinced.

I'm most familiar with https://github.com/stedolan/jq which Heroku uses to parse package.json as part their deploy setup. Semver can also solved: https://github.com/heroku/heroku-buildpack-nodejs/blob/master/lib/build.sh#L133
PR would be pointless, we can't even agree that my use case for nvm is even worth keeping this issue open for.

Yes but that would be an additional dependency to install, which currently nvm requires installing none (simply curl or wget to install node/iojs versions).
If you wrote a small commandline script that did what you wanted and supplied the version to nvm use, that would at least convince me that it's possible in a practical sense.

https://gist.github.com/assaf/ee377a186371e2e269a7

Thanks, that's great - I'm not stoked on the reliance on a heroku app for semver resolution, and the usual advice in #iojs on freenode is to put the iojs version in engines.node, so I'd expect that to be supported.
nvm_json_extract looks solid tho, even though it's a bunch of support functions.
Currently, we have nvm-exec - what would you think about adding a new executable file to the repo that, when run, prints out the contents of engines.node or engines.iojs (and perhaps picks intelligently by default, and can be overridden to only look at a provided field)? Then at least, you could do nvm use $(nvm package-json-version) or something, and that'd be a step in the direction you want, without running afoul of my semantic concerns.

If you set engines.node to 1.6.2 it will call nvm use v1.6.2. If you set engines.iojs to 1.6.2 it will call nvm use iojs-v1.6.2. If you set engines.node to 0.12.0 and engines.iojs to 1.6.2, it will call nvm use iojs-v1.6.2. It follows how people use engines today to set target versions.
The semver version is used for resolving ranges. Heroku maintains it as part of their build infrastructure, a front-end to nodejs.org/iojs.org, so it's already used by many of the people who will find this feature useful, to develop and deploy against the same version.
However, if you need repeatable builds, you should set the specific version in package.json and only that version will be used. No substitutions. And no dependencies on 3rd parties.
This works. It allows you to use package.json to specify which version of io.js/Node you want your code to run against. And it's based on a common deployment pattern (Heroku but also other PaaS influenced by them).
It does not deprecate or change existing functionality. It should still be possible use .nvmrc, but this could co-exist for developer who prefer to set the engine version in package.json and have it picked up on local, CI, and production.

Awesome, that behavior makes sense to me, thanks for clarifying.
Currently, if I don't have a .nvmrc and run nvm use, I get an error and help output - adding an additional fallback would be a breaking change (which isn't a problem, just worth noting).

I don't think it's a good idea to break current behavior.  Could be a new command, or use an alias, maybe nvm use package?

Interesting idea! As an alias, it'd have to be overridable, just like node/stable/unstable/iojs are, but maybe that's OK. That would certainly make it work with every nvm command seamlessly.

Alternatively, it could be a path, so nvm use <version | file> first looks up an alias with that name, if that fails, it looks up a file with that name. That way, it could be a shell script somewhere inside the project, pointing to the package.json in a parent directory.
And if you're in a directory that contains a package.json, nvm ls could also list that version, so you would see:
package.json -> iojs-v1.6 (-> iojs->1.6.2)

+1 to @assaf's request here. I was in the middle of coding stuff into my shell files to do exactly this when I discovered this issue. I'd also like to note that from my perspective there are big, important differences between an application and a reusable module, and many things in the npm ecosystem fail to recognize this, causing me much frustration. This is an application-driven feature request where your code is the first thing the node binary loads, and I think engines.node and engines.iojs are good ways to express an application's chosen runtime version.

I ran across this issue when I had the same thought that it would be convenient that nvm use would just pickup whatever I have in my package.json.  After reading the comments here I agree with @ljharb and can see that this will likely cause more problems than it is worth since most people probably do not use the package.json engines data like I do with CI to indicate what version of node to install on the build agent.
I would like share that you can still use the info from package.json with nvm by utilizing jq as follows:
$ nvm use $(jq -r .engines.node package.json)

And if you don't have the version installed yet, you can use the same concept with nvm install
$ nvm install $(jq -r .engines.node package.json)

Yeah, thats a lot of typing, but you could alias it if you really wanted to.

A version of grabbing engines.node without the external dependency on jq is: node -p -e 'require("./package").engines.node'

Although that won't work unless you already have node installed, which isn't something to rely on when using a node version manager :-)

Is anyone actively working on a command line nvm < use | install > package.json?

FYI, nodenv has a passable plugin api copied from rbenv.  It was pretty straightforward to build a plugin to parse package.json engines after @assaf did all the hard work :)
We're looking at using sh-semver to evaluate semver ranges without a network call or a node dependency.

Just wanted to chime in to say that I agree with @assaf's original sentiment that locking to specific node version should be encouraged -- lack of version constraint is a good thing imho, should folks choose to use engines.node

:+1: To the original suggestion. It's super helpful in having a smooth process for getting people up and running on a project locally, especially from zero. I'm imagining a workflow that would be as simple as:

clone project from Github
install NVM
nvm install package.json or something, which would install the correct version of Node and NPM for the project and npm install all the modules
npm start

Even better, if there were a way to nvm install-repo git@github.com:..., we could get rid of step 1.

@acjay that's already doable if you put .nvmrc in the github repo. then you can just run nvm install and/or nvm use and it will work.

:+1: @ljharb I somehow missed that. Still feel package.json or npm-shrinkwrap.json (latter would need a core issue) would be suitable, but that's otherwise very helpful. Thanks!

@ljharb Ah nice! So then we're just a short hop away from my dream scenario :)
But thanks for the info, I can definitely live with a .nvmrc.

The difficulty remains in using POSIX to read JSON, with no node available ¯_(ツ)_/¯

Good point!

@ljharb haven't used it, but there's this: "Pure-POSIX-shell JSON parser." https://github.com/rcrowley/json.sh (BSD-licensed)

This workaround assumes node, but would help keep .nvmrc in sync with package.json:
 "scripts": {     "preinstall": "echo $(node -p -e 'require(\"./package\").engines.node') > .nvmrc && nvm install && nvm use",
But why would nvm not be found in the sub-shell (works fine outside of npm run)?
> echo $(node -p -e 'require("./package").engines.node') > .nvmrc && nvm install && nvm use sh: 1: nvm: not found

I still think this is a good idea. I understand the point of an .nvmrc but our repos are already cluttered with dotfiles, and it seems silly to add one more just for this when there's a place for that in the package.json (which, to me, ought to be the singular point of truth for all package configuration)

@brettneese engines points to a semver range, and is and has always been purely advisory. I understand that you want the engines field to be proscriptive, but nvm shouldn't be the first tool to respect it by default (not counting warnings)/

There's also engineStrict

Which npm 3 and later have removed, because it turns out to be very bad for the ecosystem. engineStrict is dead.

Sure, ok. But straight from the docs:
You can specify the version of node that your stuff works on
Wouldn't it make sense that "the version of node that your stuff works on" is the version that NVM uses?
https://docs.npmjs.com/files/package.json#engines

The docs are inaccurate there - you can specify the versions of node that your stuff works on.
nvm doesn't work with semver ranges, it only works with a full or partial single version string - which can't be inferred from the "engines" field without a semver parser.

That, in and of itself, is not terribly difficult due to the very nature of semver. Cloudflare did it in bash here: https://github.com/cloudflare/semver_bash/blob/master/semver.sh (Not that I particularly trust anything Cloudflare does anymore ;-)) We hard-code our node versions so that's a non-issue.
I might even be willing to hack this together at some point and put in a PR to stop bikeshedding (I don't expect project owners to take care of all user requests), but given the response so far I'm not sure it'd be accepted anyway, and I'm still not sure I understand why. It does seem like that's exactly what the field is for and some deployment engines even use it (I think Heroku does, for instance, but it's been ages since I've used Heroku.)
Right now, if we were to properly follow convention, updating our node version for our project would require updating 4 files, at least (.nvmrc, Dockerfile, package.json, readme.) I found and responded to this issue because our package.json was out-of-date and I was having some issues, because, honestly, I thought package.json was our primary point of truth.
Yes, the docs also say it's advisory, but if our tools don't make our jobs easier and our workflow less convoluted, then what's the point in having them at all?

I'm always open to reviewing a PR! https://github.com/creationix/nvm/issues/651#issuecomment-85827779 is an idea to make it explicit.
I agree that having to update 4 files seems excessive - i'm not sure why the readme would mention a node version tho, nor why the Dockerfile wouldn't read it out of package.json or nvmrc?

I implemented it in bash here:
https://github.com/creationix/nvm/pull/1535

Wouldn't that be OK just to bind-to-http-resolution the nvm install (and nvm ls-remote), using package.json[engines] and somehow keep the nvm use local (without HTTP call) with a clever algorithm processing semver-specified release in package.json against installed releases.
I mean, after all nvm install will definately make some HTTP roundtrips, and "processing a semver against a list of installed versions" wouldn't be so hard, would it ?

@cyrilchapon See https://github.com/nvm-sh/nvm/issues/651#issuecomment-455380459

Would it be possible to do something like eslint-plugin-react does for React version - i.e. specify in the config file that you want to use the version specified in package.json?
// .eslintrc
{
  "settings": {
    "react": {
      "version": "detect"
    }
  }
}

Perhaps something like this:
// .nvmrc
engines.node // or whatever the property is in package.json

That could also avoid the problem of semver ranges by simply not allowing it if you wish to use this feature, as this would make the feature opt in.

That could also avoid the problem of semver ranges

Or you could specify the range as well, kinda like browserlist config.

just to compare....N does this already....according to their docs

the idea of having to specify my node version int two places is a non-starter.  No way that won't fall out of sync.

It would be really nice to add this feature:

First check if .nvmrc is present and use that version if the file exists (current behavior)
If not, check for engines.node config in package.json

Supporting strict version (i.e. "12.18.3") should be easy to implement and already a good start.

Alternatively, it's not necessary to use "engines" property. We can have our own "nvmrc" property in package.json.
The package.json can have a special field called "nvmrc" which would contain the NVM's .nvmrc file contents. It's quite easy to parse package.json with grep.
Here is how you retrieve package version (cross platform version of grep): grep -o '"version": "[^"]*' package.json | grep -o '[^"]*$'
So, NVM could check if .nvmrc file presents OR "nvmrc": "lts" value is present in package.json.
Here is bash POC:
if test -f ".nvmrc"; then
  NODE_VERSION = `cat .nvmrc || ""`
elif test -f "package.json"; then
  NODE_VERSION = `grep -o '"nvmrc": "[^"]*' package.json | grep -o '[^"]*$' || echo ""`
else
  NODE_VERSION = ""
fi

@koresar sure, an nvmrc property in package.json wouldn't be a range, it'd just be the same as .nvmrc, except then nvm would still have to have a JSON parser. Why is that better than using a .nvmrc file?

Nope. No need for JSON parser. See my POC above.
Why people want to put .nvmrc to package.json? There are answers above in this thread. My personal use case - our deployment scripts do not copy dot-files for security reasons.

@koresar many legit things live in dotfiles; that seems like a huge flaw in your deployment scripts. The majority of the answers upthread are about having a single source of truth - having two fields in the same file doesn't achieve that.
re your POC, that won't work unless there's a single space after "nvmrc": , which isn't guaranteed, and it doesn't handle a bunch of other whitespace characters that are perfectly valid in JSON. Anything that touches JSON without being a proper JSON parser is automatically broken.

@ljharb good job spotting the "space problem" in my POC. You are good with RegEx. 👍
So you probably know that this
grep -o '"version":\s*"[^"]*' package.json | grep -o '[^"]*$' || echo ""
would work with any number of space or tab characters. With some more lines of code we could make this work for new-lines as well.
I find your reply deliberately misleading and unproductive. Somehow you are looking for the proofs to tell other people are wrong, rather than collaborate effectively.
So, again, we can safely parse out single string out of a JSON file using RegEx.
Moreover, I believe that there is a 99.9999% chance that this grep would work as is. Which is high enough for production usage.
We already have two sources of truth - package.json and .nvmrc files. How come joining two sources into single source of truth doesn't achieve the requested feature?
And lastly, our deployment scripts "huge flaw" is kinda more difficult than you can imagine. There is more to that. Please, avoid basing your conclusions on my rather not informative sentence. I can' disclose more information at this point. Sorry.
Have a good day.

JSON isn't regular, so no, regular expressions simply aren't safe. I appreciate that it would work 99% of the time, but if it's not 100%, it's not safe enough for nvm.

Mate, not 99%. I said 99.9999%.
Please, avoid faking other people words. It's unproductive.
Thanks.

Good news everyone! There is a JSON parser written in pure shell script.
https://github.com/dominictarr/JSON.sh
Here is how I can 100% extract any value from a JSON file:
cat package.json | JSON.sh -b | grep '\[\"version\"\]'

This means that NVM can safely keep its version in the ["nvmrc"] (root) value of the package.json.
Who else still wants to keep the nvmrc value inside the package.json? I do. :)

@koresar ok, 99.99999999999% is still not sufficient. It's 100% or nothing.

Unfortunately, at a quick glance that tool isn't compatible with ksh due to its use of local declarations on the same line as a variable initialization.
I agree that using a full JSON parser is the only safe approach, and that one's pretty close to what we'd need - but it's still not clear that the complexity and bytes weight is a good tradeoff for being able to have your two sources of truth in the same file.

This is still an issue and I think many would like a solution.
In an ideal world, you specify the version range in package.json engines and nvm would try to infer the best thing to do - use the top end of the range?
If that isn't feasible, or specifying a specific version is still required for a use case, then specifying a specific version in addition to the range is fine, but I think it would still be better to colocate it with the engines range so that they are next to each other which should be easier to keep in sync.

This is still an issue and I think many would like a solution.
In an ideal world, you specify the version range in package.json engines and nvm would try to infer the best thing to do - use the top end of the range?
If that isn't feasible, or specifying a specific version is still required for a use case, then specifying a specific version in addition to the range is fine, but I think it would still be better to colocate it with the engines range so that they are next to each other which should be easier to keep in sync.

@theoephraim "try to infer" isn't something i'd consider ideal.
A package.json field that specifies a single nvm-style version-ish would certainly work, and could live alongside engines, but then nvm would have to add a JSON parser just to avoid a separate file.

@theoephraim "try to infer" isn't something i'd consider ideal.
A package.json field that specifies a single nvm-style version-ish would certainly work, and could live alongside engines, but then nvm would have to add a JSON parser just to avoid a separate file.

When building libraries, one may have a very wide range, so inferring may not really make sense, and throwing an error if a specific version is not specified would probably be best.
But usually for an internal project, you would have a specific version you're running in prod, and you'd like all your environments to match that. In this case, having NVM infer that you want to use 1.2.3 from a range string of "1.2.3" or "~1.2.3" seems quite reasonable, no?

When building libraries, one may have a very wide range, so inferring may not really make sense, and throwing an error if a specific version is not specified would probably be best.
But usually for an internal project, you would have a specific version you're running in prod, and you'd like all your environments to match that. In this case, having NVM infer that you want to use 1.2.3 from a range string of "1.2.3" or "~1.2.3" seems quite reasonable, no?

I understand the convenience factor there, yes. I'm not convinced that that minor convenience (having one source of truth in package.json instead of two in package.json and .nvmrc) is worth the complexity of parsing JSON.
We definitely can't assume the file is properly formatted, or that it's indented at all, let alone properly.

I understand the convenience factor there, yes. I'm not convinced that that minor convenience (having one source of truth in package.json instead of two in package.json and .nvmrc) is worth the complexity of parsing JSON.
We definitely can't assume the file is properly formatted, or that it's indented at all, let alone properly.

I definitely hear you - but... why not? This would be an optional feature - if you want to use it, it's required that you format your package.json file in the standard way. If nvm finds no nvmrc file and cant reasonably figure out what to do from your package.json file, an error is still thrown.

I definitely hear you - but... why not? This would be an optional feature - if you want to use it, it's required that you format your package.json file in the standard way. If nvm finds no nvmrc file and cant reasonably figure out what to do from your package.json file, an error is still thrown.

I've explained why not - because JSON parsing in posix would be a very complex and heavyweight thing to add to nvm.sh for a relatively insignificant benefit. It's not reasonable to have an implicit requirement that your package.json be formatted in any particular way (there is no "the" standard way), and the risk of doing the wrong thing silently is high.

I've explained why not - because JSON parsing in posix would be a very complex and heavyweight thing to add to nvm.sh for a relatively insignificant benefit. It's not reasonable to have an implicit requirement that your package.json be formatted in any particular way (there is no "the" standard way), and the risk of doing the wrong thing silently is high.

A package.json field that specifies a single nvm-style version-ish would certainly work, and could live alongside engines, but then nvm would have to add a JSON parser just to avoid a separate file.

Could it shell out to the current Node installation to use JSON.parse?

A package.json field that specifies a single nvm-style version-ish would certainly work, and could live alongside engines, but then nvm would have to add a JSON parser just to avoid a separate file.

Could it shell out to the current Node installation to use JSON.parse?

@nickmccurdy no, because we can't assume any node version is installed - the first time you run nvm install you'd want the version to be read from package.json.

@nickmccurdy no, because we can't assume any node version is installed - the first time you run nvm install you'd want the version to be read from package.json.

I do not understand the arguments "complexity of parsing JSON" and "JSON parsing in posix would be a very complex". The complexity is near 0 since there is a robust JSON.sh solution.
I do not understand the argument that JSON.sh "isn't compatible with ksh". I know that NVM gurus would solve this easily.
I do not understand the argument that JSON.sh is "heavyweight". The current NVM is 4115 lines. The JSON.sh is 180 (if you remove CLI args handling). 4115 + 180 = 4295 lines. Not heavy to me.

I do not understand the arguments "complexity of parsing JSON" and "JSON parsing in posix would be a very complex". The complexity is near 0 since there is a robust JSON.sh solution.
I do not understand the argument that JSON.sh "isn't compatible with ksh". I know that NVM gurus would solve this easily.
I do not understand the argument that JSON.sh is "heavyweight". The current NVM is 4115 lines. The JSON.sh is 180 (if you remove CLI args handling). 4115 + 180 = 4295 lines. Not heavy to me.

Weight is measured in more than lines. Inlining JSON.sh is a massive maintenance burden for me to take on - it’s vendoring a dependency, with ksh patches, replicating all their tests, and if they ever make any updates, it’s figuring out how to upstream those.

Weight is measured in more than lines. Inlining JSON.sh is a massive maintenance burden for me to take on - it’s vendoring a dependency, with ksh patches, replicating all their tests, and if they ever make any updates, it’s figuring out how to upstream those.

I understand the implementation time cost.
JSON.sh had no updates in 5 years. Not sure what to maintain there. I foresee 0 maintenance effort there. So I don't understand the "maintenance burden" argument.

I think even if we create a new field in package.json looks cleaner than and actual .rc file with just one setting

@ljharb is it acceptable to add a grammar parser? I mean it shouldn't be hard to wirte a specific grammar parser to find "engine" and "node" keywords. If I, or someone else, would write it, how I can test it to meet the acceptance criteria?

For example, I got a quick&dirty version of parser in bash, but struggle with sh. As I see in this comment, the solution should work in bash, dash, ksh, and zsh. Is this list still exhaustive? What's about semver?

The list includes those 5, yes.
To safely parse json requires a full json parser, regardless of the property names being located.

About JSON parsers. I invite everyone to read this issue starting from the comment: https://github.com/nvm-sh/nvm/issues/651#issuecomment-701360709
In other words, it was already discussed.

But, well, the proposed parser doesn't fulfill criteria of nvm. It just doesn't work on all target platforms.

This is something that came across my mind at work this week... Then I saw this issue, created Feb 2015 😬
I tried to come at this from a different angle:
Rather than getting nvm to read package.json, why not at least automatically create an .nvmrc file based on package.json so things can stay in sync & nvm can use it?
I'm not sure if there's anything else that does that out there, maybe there is... it's quite simple... but here is my effort to solve one of the issues I think people are trying to solve here (that being, not having to declare the same thing in two different places) https://www.npmjs.com/package/package-node-to-nvmrc.

From my perspective, making it an opt-in feature (by not creating an .nvmrc file) that may have some harsh limitations in order to use it (like formatting your package.json file a certain way that would allow us to detect the version using a simple regex) would be a very reasonable compromise that could help many people. It could even log a big nasty warning whenever the feature is triggered saying something like:
Autodetected node version using package.json engines - using version "X.Y.Z"
If this was not what you expected, please follow the package.json formatting restrictions listed <here> or just define an .nvmrc file

For a huge number of projects, it would just work as expected. In a few cases, it would try to run but be unable to detect a version and throw an error. In a very small set of cases, it may do something unexpected. A developer hitting those edge cases could either then try to adjust their package.json file until it does what they were expecting, or create an .nvmrc file.

@rubengmurray that's a great approach, except that it uses husky, which is a very dangerous thing (automatically installed git hooks, i mean, not just that specific tool)
@theoephraim it would have to only ever have false negatives - iow, it might be ok if it fails wrongly, but it's not ok if it installed the wrong version wrongly.

@ljharb Interesting... I'm not so experienced with git hooks to be honest, husky just seemed an easy way to implement the hook. Why it is they're 'very dangerous'... Is there potential for clash / overwrite with existing .git/hooks/pre-commit?

@rubengmurray it's a security hole. there's a reason git itself doesn't allow you to ship automatically-installed git hooks with a repo.

But, well, the proposed parser doesn't fulfill criteria of nvm. It just doesn't work on all target platforms.

I think we discussed that already. We came to conclusion that it would be quite easy for Shell gurus to adopt that parser to all (actually one) target platforms.

https://itnext.io/locking-the-node-js-version-in-your-projects-70268c877421
For now, perhaps this is the "best" answer? It allows us to define our specific (not minimum) version in node.engines, have (and get benefits of) .nvmrc, but also have explicit node defined (and switched to); all while maintaining a single point of truth in package.json.

If you mean autogenerating nvmrc, sure, that’s totally viable.

@ljharb Just some food for thoughts, what about making use of the fact that Yarn and NPM can both parse package.json?
For example here is my current solution to enforce one node version in one place only:
package.json
{
  "engines": {
    "node": "16"
  },
  "scripts": {
    "nv": "echo $npm_package_engines_node"
  }
}

Use the version specified in package.json:
nvm use $(yarn -s nv)

or
nvm use $(npm run -s nv)

Those package vars i believe don't work anymore, and either way, nvm has to be able to work with no node versions installed.

Ok that's fair enough!

I propose this in package.json. I.e. avoid using existing "engines" property:
{
  // ...
  "nvm": "16"
  // ...
}

@koresar sure, that would solve the "range" problem but would still have two problems: needing to parse JSON, and having two sources of truth (since engines.node still exists)

We already have two source of truth nowadays: package.json and .nvmrc (but package.json is ignored but NVM atm)
JSON parsing is a solved problem. JSON can be reliably parsed with just 100 LOC. See https://github.com/nvm-sh/nvm/issues/651#issuecomment-769483899

@ljharb I think I debunked the argument "problem of JSON parsing" two times in this issue. It is actually not a problem. Google: JSON.sh
The only actual argument I saw here is "implementation time cost". It is indeed a downside.

That is why it is a huge problem - not because it’s impossible, but because the complexity and byte size required to do it is prohibitive massive. 100 lines of dense code is WAY too much to casually add it to nvm.
If the issue were “debunked” then nvm would have the feature; it continues to be an issue, which is why this remains open.

A few months ago I came up with my own solution for this I personally think is preferable to having this feature as a part of nvm because it could be used on both Windows and Mac. I use nvm-windows which is similar but different to this particular project, but the API is similar, so your mileage may vary.

after installing nvm, install the latest node version, just so you can run npm

nvm install node && nvm use node

when you need to use engines, use the environment variable from npm, like $npm_package_engines_node

I use windows, so I use cross-env to use the environment variable, like this:

npm install -g cross-env && cross-env-shell nvm install $npm_package_engines_node && cross-env-shell nvm use $npm_package_engines_node

wrap it all up within an npm script, so you can call it (we installed the latest node in step 1)

"scripts": {
  "setup": "npm install -g cross-env && cross-env-shell nvm install $npm_package_engines_node && cross-env-shell nvm use $npm_package_engines_node && npm install"
},

run the script whenever you're switching projects, or when you are building in CInpm run setup

To recap:
The first time, you can install whatever node version you want. Any other time, you only need to run npm run setup. Kind of weird in CI environments which are built from scratch on each run, because you install the latest node and then immediately install a different node. But if you're OK with that, it just works.
I don't know if using npm to install npm will shatter dimensions, but it hasn't caused an issue for me yet.

As an alternative to coding this directly into nvm, you can add it to the shell script located in the README

NOTE: This does not handle semantic versions in the node engine property

# Calling nvm use automatically in a directory with a .nvmrc or package.json file
autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"

  # Check for .nvmrc
  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi

    return
  fi

  # Check for node engine in package.json
  if [ -f package.json ]; then
    local pkg_node_version=$(jq -r .engines.node package.json)
    if [ "$pkg_node_version" != "null" ]; then
      local nvmrc_node_version=$(nvm version "$pkg_node_version")
      if [ "$nvmrc_node_version" = "N/A" ]; then
        nvm install "$pkg_node_version"
      elif [ "$nvmrc_node_version" != "$node_version" ]; then
    	nvm use "$pkg_node_version"
      fi
      return
    fi
  fi

  # Default nvm version
  if [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

As an alternative to coding this directly into nvm, you can add it to the shell script located in the README

NOTE: This does not handle semantic versions in the node engine property and requires that jq be installed.

# Calling nvm use automatically in a directory with a .nvmrc or package.json file
autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"

  # Check for .nvmrc
  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi

    return
  fi

  # Check for node engine in package.json
  if [ -f package.json ]; then
    local pkg_node_version=$(jq -r .engines.node package.json)
    if [ "$pkg_node_version" != "null" ]; then
      local nvmrc_node_version=$(nvm version "$pkg_node_version")
      if [ "$nvmrc_node_version" = "N/A" ]; then
        nvm install "$pkg_node_version"
      elif [ "$nvmrc_node_version" != "$node_version" ]; then
    	nvm use "$pkg_node_version"
      fi
      return
    fi
  fi

  # Default nvm version
  if [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

Hi! Any news on this?

@sebacruz no, like every issue on GitHub ever, if there’s news, it would be posted on the issue

@ljharb you are right, sorry for my meaningless comment.

@ljharb your rationale on this topic is invalid and you are just being stubborn. Bad luck for a great project.
thanks to that me as many others need to resolve to some kind of workaround without any good reason. Argument: "I cannot parse json" is retarded.
100 lines of code are prohibitive for you? Is this some contest of best utility below 12kb or what?

@d-lach how is my rationale “invalid”? Factually, package.json engines.node supports a semver range, and a version manager requires a single version. They’re conceptually incompatible.
Adding a config file to the project is basically zero pain - it’s just a file in the filesystem. It may be redundant if you are an app (not a published package) and are using engines.node in a manner it was not designed for - to constrain developers to a specific version of node - but the problem here is that npm simply doesn’t offer a “dev engines” feature for this. nvm not supporting a feature that doesn’t exist is perfectly rational.
Additionally, your use of the word “retarded” in this context is a blatant violation of this projects code of conduct; please edit your comment and be more careful in the future.

actually, package.json engines.node supports a semver range, and a version manager requires a single version. They’re conceptually incompatible.

@ljharb sorry but that's being narrow-minded IMHO.
const isSemver = // [...]

if (isSemver) {
  console.log('Nvm is only compatible with package.json `engine` single version scheme. Semver range detected')
  return
}

// Else do the job

??

Adding a config file to the project is basically zero pain - it’s just a file in the filesystem.
You are basically avoiding the (actual) arguments out there. Let me quote them for you :

assaf commented on 24 Mar 2015

It's actually very convenient when everyone on the team, the CI server, and production servers all pick the same version, based on package.json. And a huge time saved when shuffling between multiple projects (consulting, microservices, migration, etc).

The point is not "creating a file". The point is MAINTAINING a file.

@cyrilchapon that might encourage people to put a single version of node in engines for their published package, which if it happened once would cause far more damage than an eternity of “extra config files”.
I completely understand the difficulty of having two sources of truth. I would vastly prefer npm to add a devEngines field, which then nvm would use, with the range checking you’re talking about.
What all my employers have done is to add a CI job that errors when nvmrc and package.json engines.node aren’t in sync. It’s annoying to have to set it up, but it’s 5 minutes of work, once.

Would this project be willing to support devEngines [soon]? Those of us who aren't concerned with our package.json following a strict schema (we're willing to add devEngines) could then at least have both versions inside the same package.json.

@rainabba the instant npm supports it, i will immediately work towards getting nvm to respect it. I'd encourage you to file an npm RFC.

@d-lach how is my rationale “invalid”? Factually, package.json engines.node supports a semver range, and a version manager requires a single version. They’re conceptually incompatible.

They are different but not conceptualy incompatible since single version required by a manager needs to be in the defined semver range. So the version you probably want to use can be determined based on defined semver. It can be either the most recent or the oldest version in the range. If the range is specified, then any version you choose as a version manager should be correct - you will be able to use the project.

Adding a config file to the project is basically zero pain - it’s just a file in the filesystem.

As someone said before the pain is maintaining a file while there are 2 sources of true.

It may be redundant if you are an app (not a published package) and are using engines.node in a manner it was not designed for - to constrain developers, instead of package consumers, to a specific version of node - but the problem here is that npm simply doesn’t offer a “dev engines” feature for this. nvm not supporting a feature that doesn’t exist is perfectly rational.

You are looking just from the perspective of the package developer while in reality majority of devs are consumers, not publishers of packages. In my scenario we specify the range for two reasons:

to make sure that the VM on which the app is deployed has node version which we were developing with or we have tested (narrow semver range)
to make sure that all devs use proper version during development

I do not think that npm needs to support "dev engines" in order for nvm to figure out which version you can use for work with a project since for all cases except working on a package, you work on the same version (same range) for which you deploy - and we need nvm exactly for that reason!

Additionally, your use of the word “retarded” in this context is a blatant violation of this projects code of conduct; please edit your comment and be more careful in the future.

Sorry, I have adjusted to that.

@d-lach it is quite true that package maintainers are vastly outnumbered by node users/package consumers. However, if nvm causes a single maintainer to accidentally publish a package with an incorrect engines.node field, many millions of consumers will be impacted. That's why it's always paramount to ensure safe workflows for maintainers before appeasing inconvenience for consumers.

Would this project be willing to support devEngines [soon]? Those of us who aren't concerned with our package.json following a strict schema (we're willing to add devEngines) could then at least have both versions inside the same package.json.

@rainabba Why develop with an engine that isn't the production engine? If a developer is using node 16 on their machine but the code base runs in a node 12 environment, then they may very easily run into troubles with using syntax that is supported by node 16 but not by node 12; for example the nullish coalescing operator (??) was introduced in node 13.

If nvm causes a single maintainer to accidentally publish a package with an incorrect engines.node field, many millions of consumers will be impacted.

@ljharb The engines filed is an advisory field only and shouldn't affect millions of consumers. The only case where this isn't true is when the engine-strict option is set to true. I've shared the relevant npm documentation below for reference.

Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#engines

@stuft2 that's not entirely true at this point; yarn errors when engines mismatch, and npm 7+ will intelligently select an older version if doing so would satisfy otherwise invalid engines requirements.

@ljharb from what you say about broken engine property I get that you miss the point.
What ppl in this tread are asking for is:
NVM should use reasonable default - latest or oldest version choosen from the range specified in package.json.
If nvmrc is present then use version from nvmrc.
thats all!
Thanks to that most of the devs will be able to ommit nvmrc completly and still benefit from nvm use.
No harm will be done to package devs and package.json will be in line with specification.

in the range specified in package.json

Personally, I'm not interested in range or semver or other patterns. Just an exact version will cover all my needs. I'm fine if nvm would throw an error on unsupported patterns.

in the range specified in package.json

Personally, I'm not interested in range or semver or other patterns. Just an exact version will cover all my needs. I'm fine if nvm would throw an error on unsupported patterns.

This is a no go for reasons @ljharb has pointed out above. Namely It will make you to missuse engines property which should be use to specify node target engines range and it's critical for packages definition.

@d-lach using engines.node is simply not a reasonable default; that's the problem.
@Bessonov that would be fine on a field that's meant for developers of the project - engines is meant for consumers of the project.

@d-lach using engines.node is simply not a reasonable default; that's the problem.

Do you have any argument for that statment?

@d-lach i've presented many times higher up the thread. It is nonsensical to use a field designed to advise consumers what range of node versions is supported, to mean "the single version developers should use on this project". Even if this made sense, some developers might want "the lowest in-range version" to be selected - and some might want "the latest in-range version". There's just no clear semantics to choose.

I can imagine that a large part of this discussion comes down to the fact that the field allows for ranges, but most developers of projects they control don't put a range in semicolon they put the exact version of node which they are building the project to run on. The semantic version might make sense for packages meant to be used in a wide range of environments, but NVM doesn't apply to those use cases since as has been made so clear, it requires a specific version of node.
I don't believe I've seen a reason why NVM could not use the value when it specifies a single version of node (no ambiguity). Did I miss something?

@rainabba i completely agree that for apps, that’s what people do. If nvm only supported engines.node when it was a single version - but had no way to know it’s an app or not (since there’s no reliable way to know that) - then there is a risk that a package maintainer will put a single version there so they can use nvm, not realizing that it will break their consumers who aren’t on that version. This risk is unacceptable to me.

engines is meant for consumers of the project.

Thank for clarification. IDK why I miss that above, probably parallel tasks, sorry. But TBH I'm not sure how it can work. Usually, thousands of dependencies are used. This will lead surely to version conflicts, even if there is no problems with functionality. And then someone must decide on a single used version anyway. I think better primitives would be features, not versions. This doesn't resolve lower/higher version problem described above. But I would vote for higher version, at least from security point of view.
I'm fine to use another attribute with an exact version and I don't care about its name.

@ljharb you seems to be oblivious to the fact that vast majority of devs are consumers of their own packages. I won't even try to explain again the rationale and benefit of automatically figuring out "the single version developers should use on this project" based on "supported range of node versions" in such a case.

d-lach commented

I won't even try to explain again the rationale and benefit of automatically figuring out "the single version developers should use on this project" based on "supported range of node versions" in such a case

We got it, then the discussion went forward. Move on ? You're the one being narrow minded now — and the "customer" attitude you're having here is not appropriate at all. Go on, fork it, and better pull request it if you have time for it. I'm pretty sure @ljharb will be perfectly up to review it.

So 2 things here :

The fact package.json uses semver ranges. @ljharb consider this not reliable, not precise enough and, say, not allowing to guess the "best version"
The fact engines.node is actually not designed to advise the "development" node release, but rather the "run" node release

1 is debatable IMHO. nvm install node installs latest node after all. nvm install lts too in it's range. nvm install package could follow the same logic.
The "node" definition in nvm install node could be conceptually seen as a "semver" range roughly; same goes for "lts". What do you think @ljharb ?

2 is harder.
d-lach commented

@ljharb you seems to be oblivious to the fact that vast majority of devs are consumers of their own packages.

That's a pretty invalid argument. Majority of devs being consumer of their own packages is obvious. The important thing is "are the majority of consumers the dev of the package"; and that's clearly not the case.

ljharb commented
that would be fine on a field that's meant for developers of the project - engines is meant for consumers of the project.

Well that's a good point; and the discussion around devEngines is an interesting path.

We got it, then the discussion went forward. Move on ? You're the one being narrow minded now — and the "customer" attitude you're having here is not appropriate at all. Go on, fork it, and better pull request it if you have time for it. I'm pretty sure @ljharb will be perfectly up to review it.

@cyrilchapon This discussion has not moved forward over past 6 years so I would rather skip a review from that guy.

That's a pretty invalid argument. Majority of devs being consumer of their own packages is obvious. The important thing is "is the majority of consumers of a package, the dev of that package ?"; and that's clearly not the case.

Sorry, I meant what you said: "majority of consumers of a package are devs of a package". This is the case for all packages which are not published- so all apps and devs working commercialy.

Even if the ratio of consumers to publishers is 1:1e6, it’s still more important to make sure the publisher use case is safe by default. If i make a mistake in the wrong one of my packages, i can break 50 million people in a matter of seconds.

@zoobot there's an open PR, but it's still in discussion stage, since engines.node is a range, and not intended to indicate the current node environment's singular version.

@zoobot what i've usually seen in my previous employers is an .nvmrc file, and a separate CI check that verifies that .nvmrc satisfies the range in engines.node. That way, you still have to update two places, but you can't forget to do it.
The PR is #1535.

I am glad to see that there is still interest to look into this, I hope we get a solution soon!

+1 to this feature request!
My 2c: my current company has an engines field, which is useful because it warns you on npm ci if you're using a node version that falls out of this range.
Since this warning is important, and for other reasons, we can't remove the engines entry in package.json. Hence, adding a .nvmrc would be duplicated data — which is problematic, because if we updated one, we'd need to remember to update the other.
We could solve that problem with automation — a step that makes sure .nvmrc and engines.node are the same in CI, but that seems overkill.
nvm use (with no further args) consuming package.json's engines.node field could be opt-in if we needed to make sure this is a backwards-compatible change.

@lautarodragan indeed, "automation" is how that's been solved at all of my past employers.
(re jq, you can use npx json instead, i believe, and it should work the same)

(My query may sound a bit off topic and naive)
In my project, I have updated node version in .nvmrc file to latest LTS node version - 18.14.2 (previously it was some other version)
The template that I was using to spin up the project had engines.node version range >=14.15.0
Query 1: On updating .nvmrc node version, is node.engines version supposed to be updated to some other value automatically / manually?
Query 2: Other node-like dependencies, for example, @types/nodes(I am using typescript) version is 14.14.25. Is that also supposed to be updated to some v18 version?
Query 3: if .nvmrc is guiding the project's overall node version, why are other (node)dependencies in package.json not updating themselves? What is the overall process like?
Thanks

@ljharb is there was a way use to npx json inside .nvmrc instead of running it as a command every-time? and you're right. npx json works like jq

nvm can't assume that node is already available, so it can't run npx.

Here's my solution, supports engines and ranged semver, maybe nvm can borrow some ideas from it:
https://github.com/ysmood/use-node

I'm following this simple approach
alias nv="cat package.json | grep '\"node\": ' | grep -o '[0-9.]*'"
nv | xargs -0 -I{} nvm use {}

Careful with that; JSON doesnt require a space after the colon, and npm dist-tags i believe can also be used there.

For anyone interested, i created package called nvm-auto that uses version from engines field, it also supports semver ranges.
https://www.npmjs.com/package/nvm-auto
Simple usage:
npx nvm-auto

Works for nvm and nvm-windows

@maintainers tl;dr.  If I submit a patch that adds this feature, would you land it?

@vegerot not necessarily, or else the "pull request wanted" label would be on the issue. Additionally, see #1535..

Can we have the behavior so it uses the engines property and if that doesn't exist then it uses the version in .nvmrc

@hichemfantar see https://github.com/nvm-sh/nvm/issues/651#issuecomment-85263809

for anyone else stumbling across this 10 year old issue, fnm supports using the engines field.

Resolved finally, thanks @theoephraim !
@ljharb hiding the best answer yet as a spam?


[#22] add call back to delegate

What happened 👀
Describe the big picture of your changes here to communicate to the team why we should accept this pull request.
Insight 📝
Describe in details how to test the changes, which solution you tried but did not go with, referenced documentation is welcome as well.
Proof Of Work 📹

@blyscuit it's working actually, could you mark it as ready for review? it's to merge to the base branch

I thought you can copy the code to your PR and we can close this one. This is just a POC.

@blyscuit it's working actually, could you mark it as ready for review? it's to merge to the base branch


Added MSI GC20 V2 (variant).

I previously sent an MSI GC20 configuration taken from Steam. From another dev software (Godot Joypad Demo Tool) I had another serial and a slightly different configuration. This one I manually remapped the buttons, so I'm sure it's ok. I suggest you to keep both.

I seen a button used twice. Maybe the program has some issue.


Merge Smart Contracts Master from VSTS

This is a work in progress.
PLEASE DON'T MERGE

Is this supposed to be reviewed?

@noescape00 this will have an initial review with myself and Dan tomorrow 👍

Maybe let's split it into several small PRs to expose it to a broader audience so it's possible to review it?

@noescape00 this won't be possible in this instance as we are literally merging the whole Smart Contract VSTS master to Full Node. It has been cleaned up over the last few months to ensure that basically only smart contract code gets introduced into the full node and is contained as such.
You can review the code that was changed that relates to the existing full node code only, should you wish to do so. After the merge is complete there will be opportunity for reviewing the smart contract code and recommending changes as and when.

@fassadlr so there is no code here that's going inside the full node? Only new projects?

It was agreed with @fassadlr that

coinvew changes will be fix on this branch (so to role back changes in fullnodebuilder)

Then we commit this code (so the guys can work on master)
@fassadlr will then create two new projects and move parts of the code that are SC specific.

SmartContractWallet
SmartContract.IntegrationTests

This is not ideal but the alternative is long discussions on an already big PR.
@bokobza @noescape00 @Aprogiena please review the parts that are related to the fullnode and make some comments on stuff that are breaking the code (not styling).
Not for this review anything under (not to bulk the comment history)
Stratis.Bitcoin.Features.SmartContracts
Stratis.SmartContracts.*
Do we agree?

Can we make a separated PR that includes all the changes to the full node code and nothing else? If yes, I will be able to view that. Still not sure what you mean by not styling.

It was considered but its gonna be hard, I can suggest using the VS plugin then its easy to see what are the changes to the FN.

@dangershony all chains has synced and staking still works as per normal. Lets MERGE this beast!

I have done a once-over off the diff. The main changes I see:

Some visibility changes, required so smart contracts can override things
Addition of IVersionProvider and IScriptAddressReader and their implementations, which move existing functionality to an abstraction
Refactoring of StandardTransactionPolicy to allow some methods to be overridden

If it is not possible to separate, which I still don't understand why it wouldn't be, I will need to try to review it as is, so please be patient.

@Aprogiena give me a few minutes and I will separate the FN specific changes into a new branch

@Aprogiena See diff here: https://github.com/stratisproject/StratisBitcoinFullNode/compare/master...rowandh:sc-fn-changes?expand=1
These are all the changes to existing FN code. That's anything outside of the Stratis.SmartContracts namespace, and excluding a few smart contract-specific files in the integration tests. There might be some stuff in there I've missed.
Consider this for ease of review only. If we merge that branch because we will lose our commit history.

Thanks @rowandh for creating a  diff.
Yes generally I am happy to push this as is and any changes that are not critical on FN can be fixed after the push.
Reason is so we can get this over with.

do you guys plan mergin this today?

I'm looking at it.
Just FYI, if you wanted us to review ad push the full node stuff first, you can

make changes in the full node
it's reviewed and merged in master
master is merged into the SC branch
you resubmit the SC branch
--> no change in the full node can be seen.

@fassadlr @rowandh

@dangershony @bokobza I have now merged the FN into this branch and it is now ready to be pushed. Awesome.

Just 1 last merge @fassadlr please 😭


Create an LedgerClient impl for talking to actual chain

Good chance we can just wrap the CNCLI or something similar with a port adapter. I haven't spent a lot of time looking into what this will take. Good chance this could be broken down into a feature with multiple tasks.

I'm actually going to prioritize writing a BlockFrost client, rather than talking to a client. That makes things even easier.

This MR did Output lookup for a BaseAddress.

Did this forever ago :P


Fill NodeInfo in CreateFromKey method in scheduler

NodeInfo was nil and it caused segfault
Fixes #5503

cc @gmarek @lavalamp

It's related to #5351

Merging.


Create monthly report for April

Encompassing February and March progress, first report of the "new" re porting period.
It should improve format based on feedback and include as well monthly prioritisation and justification for it so it can be properly discussed.
Refer to https://github.com/alan-turing-institute/data-safe-haven-team/pull/69/files for feedback, as well as the monthly meeting notes https://hackmd.io/jPtV0qljTDG-6K9DDU1mPw

Report feedback

[ ] add dates
[ ] Chronological order for actions rather than reverse

Comprenhensive summaries are even better than any list

[ ] Add DoD as much as possible

Unresolved conversation from previous report

Documentation management definition of done

I am (have been) finding it difficult to turn weekly reports into monthly reports, due to lack of clarity on what the short terms goals are and why. We end up with statement on the actions but with little context, to some extent comments from planning meeting should help to this and I could include that into the report (and weekly?)

Proposed sprints should be included for consideration https://hackmd.io/@nHslnPpLRmCxPOmQBcOW-g/Byy0S9RKT


Apple silicon simulator support in the add-on

This is done in this PR, but we will need an official release of mobile-native-ios to verify that everything works.

Everything works as far as I can tell.


Is this package supported for Android 11?

I have implemented this package in my android app and this feature is working for all android versions except android 11, please tell me if this is supported to android 11?
This is my implementation:
onPressed: () async{                   const url = 'https://youtu.be/example';                   if (await canLaunch(url)){                     await launch(url);                   } else {                     log('problem in url');                   }                 },

This is due to a change in Android 11 (https://developer.android.com/about/versions/11/privacy/package-visibility).
Add the following code to your manifest node.
 <queries>
        <intent>
            <action android:name="android.intent.action.VIEW" />
            <data android:scheme="https" />
        </intent>
</queries>

Thank you for your reply


Instability cloud reader

There seems to be some stability issues when reading from the cloud object store with the native parquet reader.

You sometimes get 404 body not found, however changing the path from abfss or abfs might then suddenly work within the same python session, restarting the python session also resolves it.
Doing consecutive reads to the cloud from behind a VPN causes it to fail after around 10 calls, throwing TCP connection errors

Need to resolve this before releasing it.


Externally reusable proc macro exports transformation

Feature
I'd like to be able to reuse and modify the output of macros like wit-bindgen::generate and wasmtime::component::bindgen
Benefit
Users will be able to build on the code generated by *bindgen crates.
This is a somewhat "backdoor" way of solving the following other issues:
https://github.com/bytecodealliance/wit-bindgen/issues/554
https://github.com/WebAssembly/component-model/issues/58 (it probably does not make sense to make annotations, but language specific bindgen modification probably makes more sense)
Implementation
To make that happen, I'd like to move top level (and possibly lower) macro functionality (ex. functions with the signature (input: proc_macro::InputStream) -> proc_macro::InputStream) to a separate crate(s) that exports the transformations (and configuration/Parse impls necessary), and publish those separately, with a re-export under the original packages.
Alternatives
Alternatively, people can make partial copies of the current existing crates in order to use the functionality therein.
I've done this, and while it does work, it introduces an unnecessary partial vendoring of wasmtime in the downstream crate. Certainly a reasonable stop gap solution, but it would be much preferred if the import could boil down to mostly one dependency on a crate like wit-bindgen-macros/wit-bindgen-macro-util.

This would certainly be great. I am currently also using the workaround of manually copying the macro crate's code so that I can modify the outcoming TokenStream, for example here.
I have already created this issue in the past, but was closed. I think @alexcrichton didn't understand what I wanted, so let me re-iterate:
All that we are asking for is that the wasmtime_component_macro (and the wit-bindgen equivalent for the guest) is split into two: one that exports the macros as normal functions with TokenStream -> TokenStream signatures, and a second crate that just re-exports those functions as proc macros.
That's all. I don't expect any support in terms of "stability" of the resulting code from the macro or anything like that.

At least personally I don't have much more to add over what I already mentioned. I apologize if you felt misunderstood, but I feel like I understand what you're saying and asking for and what I'm trying to explain is why it may seem like a simple ask it's not as simple as it appears on the surface and I don't think is something we should take on maintaining.
The more "public surface area" of Wasmtime that folks use the more we inevitably get pushback when making changes or issues whenever changes are made. These aren't something we are really planning on maintaining beyond the interfaces that are intended.
My recommendation is still to either (a) copy and vendor the sources yourself to take on the maintenance burden yourselves or (b) work on integrating these features upstream here in Wasmtime.

Hey @alexcrichton apologies I searched but somehow didn't see that other thread! I made this thread thinking I was late to making one at all in the official repo after asking on Zulip.
My apologies -- the workaround as noted is fine (as is trying to integrate the features in jiving with Wasmtime proper).

@alexcrichton I understand what you're saying and asking for ... I don't think is something we should take on maintaining. I am not asking you to maintain the output of the proc macro any more than you do already. Let me explain it this way:
Wasmtime version 12 released, so to update my code, I have to:

Find the proc macro repository on github
Manually update the Cargo.toml dependencies, some of which are workspace dependencies, so this includes sifting through the code and finding the actual versions
Manually copy the new source code
Fix any problems that are created by using a new (and not necessarily compatible) version of the proc macro

Now let's compare this to how this would look like if the proc macro crates were split in two:

Update the version of the dependent proc macro crate to 12.something
Fix any problems that are created by using a new (and not necessarily compatible) version of the proc macro

The point 4 is exactly the same, because it's exactly the same code. So how is the first approach better?
I do not understand what "maintaining" are you talking about, I am not asking you to maintain anything, just split the crate in two and do everything else the same way you are doing.

To expand on this, I can say yes I understand what you're saying @kajacx and I additionally understand how that is appealing from your perspective. From your perspective I agree that it's less work for you and doesn't seem too add much maintenance on the project.
From Wasmtime's perspective, however, there's a few issues in my opinion:

There's no reason for this split in the sense that if someone changes it there's no test that will fail or reason to keep it the way it is. This means that it can change at any time, and a request in the future to change it back to the way it was is, in my opinion, maintenance.
You may not be the only user of this feature. While you may be willing to update when Wasmtime changes others may be less willing and may open issues here asking for guidance in updating, request that changes be backed out, or something like that.
More generally even if users use a feature like this and update just fine there may be subtle runtime or other issues which aren't predicted since we, the maintainers of wasmtime, aren't necessarily going into this eyes open. This means that subtle issues may arise into our issue queue which we then debug and spend time on which end up bottoming out in code elsewhere we can't do much about.

Personally I'd prefer to avoid these situations. I understand that the distinctions I'm making are subtle and somewhat hand-wavy as well. To be clear I'm just one maintainer here and there are many others, so if others are willing to help you carry through a change like this I'm happy to hand it off to them.


msl/build-urcrypt

TODO:

[ ] Derivation for libsecp256k1
[ ] Derivation for libaes_siv
[ ] Derivation for libcrypto

Closing in favor of #123 cc @ashelkovnykov


$500 Bounty - Official SwipeRefreshLayout for Android (PTR for iOS already solved)

--->
Is your feature request related to a problem? If so, Please describe.
Hi folks!
I work at a tech company and we'd like to have the below feature in 1265 (already supported for iOS) to also be "officially" supported for Android as well (in react-native-webview)
https://github.com/react-native-webview/react-native-webview/pull/1265 (this is the iOS feature)
https://github.com/react-native-webview/react-native-webview/issues/2468 (this is the issue we want to solve to also support this for Android)
Technically, someone got 2468 "working-ish" - but it's some random forked code, and we'd prefer a version that could be merged back into the main open source project / codebase 👍
$500 in it for the person who can solve and merge into main project!

Describe the solutions you came up with

Additional context

https://github.com/react-native-webview/react-native-webview/pull/2787
Fixed the SwipeRefreshLayout for webview (android platform) and generated a pull request.
Waiting for review.


Cosmos Spark: Added option to override the MicroBatchPayloadSize in bytes

Description
Added option to override the MicroBatchPayloadSize in bytes from Spark connector to accommodate better efficiency when documents are large > 110KB
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.


Federated identity credentials Azure CLI commands

Resource Provider
Azure Identity team
Description of Feature or Work Requested
Update/creation of Azure CLI commands to support the Federated identity credentials feature (https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation). Detailed spec here: https://microsoft.sharepoint.com/:w:/t/Identity-DevEx/Ecdj6sRt6uNOg_o4uxLZHW8BSkZxPxgdGLL0Sg8_Q6VtXQ?e=ICyONF
Minimum API Version Required
Currently the API is in beta but will GA early next year (Feb 2022 timeframe)
Swagger Link
Swagger file for Microsoft Graph API - OpenAPI description for applications module in staging beta (github.com).
The API paths of interest are:

/applications/{application-id}/federatedIdentityCredentials/*
/servicePrincipals/{servicePrincipal-id}/federatedIdentityCredentials/*

Target Date
Feb/Mar 2022 timeframe (to align with GA of the Federated identity credentials API)

@jiasli for awareness

PowerShell? Perhaps it should be Azure CLI. 😉

Good catch Jiashuo - updated just now. :)

@jiasli and @yonzhan
This is a complex configuration that I have researched and scripted extensively.
I have created a script here - that guides the user in setting this up and I expect the Azure CLI feature to do the same.
https://github.com/jongio/github-azure-oidc/blob/main/oidc.sh

The CLI should allow the user to pass in a federatedIdentityCredential.json file or stream that allows them to create multiple FICs.

See the example here: https://github.com/jongio/github-azure-oidc/blob/main/fics.json

The FIC creation call to the graph API has false positives. Meaning that the call to create the FIC returns as success, but in fact it is never created.  So to ensure this API works correctly that bug needs to be fixed and in the meantime the Azure CLI should verify that the FICs are indeed created.

You can learn more about OIDC with this video: https://youtu.be/r5QdsjjdRDs
Jon

@yonzhan I am taking over from Kevin on this feature. Do I understand correctly that this work is scheduled for your April sprint, and we can expect it to complete by May 3?
I have some edits I'd like to make to the design of the proposed commands. Can you please sync up with me on that before starting implementation?

@dstrockis Good to know you are working on the design. You could send me an email about the design offline and this feature is already planned in Cu semester. My alias is yonzhan


Flatpickr with MDC field is wrong rendered

Your Environment

flatpickr version used: 4.5.2
Browser name and version: Google Chrome (73) and Firefox (64) (i didn't check another)
OS and version: Windows 10

Hey, I have a problem with flatpickr in the bootstrap modal with MDC fields and buttons. I think modal is not a problem, but I recreate visually it here:
https://jsfiddle.net/1metp50o/1/ - try open flatpickr on the first field and look when second field (mdc) and MDC button is on the flatpickr.
I tried find a problem in the code and flatpickr-wrapper is rendered around input field, but should be (for mdc) rendered after whole field element.
This should be rendered something like that:

    <input>

<flatpickr-wrapper>

But it is rendered like that:

    <flatpickr-wrapper>
        <input>
        <flatpickr-calendar>
    </flatpickr-wrapper>

My question is: How set a place (possible?), where should be flatpickr rendered for the static option? Should it be onReady hook or maybe this is impossible? Let me know something about it.
// Edit: z-index will not help with that.

You can tell flatpickr where to be appended using the appendTo config flag and giving it an HTMLElement. If you need it after a specific div, you can create an empty div where you need it and appendTo it

@viorelsfetea It's looks like appendTo not working for the static: true, Any some ideas?

appendTo is redundant to static. static puts the calendar in the same container as the input, appendTo puts the calendar where you need it. If the calendar is miss positioned, it's a CSS issue for the wrapper you appended to

Okey. Append is properly, but I needed set new position for wrapper. I don't why positions is bad, maybe by for modal. I did it in the onOpen and onChange hooks. If someone will have a problem like mine, ping me, I will try to help. I think we can close it. Thanks for your time @viorelsfetea .

Glad to help!


Sometimes all images get loaded at once

I have a very simple page setup. It's a container with images underneath each other. Sometimes all images get loaded at once. I don't know why this happens. All my  elements have heights set.

hey @bramvdplujim can you please share your issue using jsfiddle

I can get it to hit here and it also renders kind of funny:
https://codesandbox.io/s/jzjzzr594y


usm: go-tls: Fix typo in error message

What does this PR do?
Fix a small typo in an error message. This error message is visible in the recorded block reasons or when performing a manual attach via the debug endpoint.
Motivation
Cleanup.
Describe how you validated your changes
Covered by automated tests.

Possible Drawbacks / Trade-offs
Additional Notes

/merge


Deps/upgrade to storybook 7

Storybook 7 has been released and it has a ton of breaking changes. In this branch, I've done the easy parts of the migrations, but the remaining part consists of migrating all of the docs files of all of our hooks into the new format.
Before committing huge amounts time to this, I would like to discuss, should we do this or something else potentially? Moving to Docusaurus has been suggested before. Now might be the time to do that. We could also just stay in Storybook 6 for now.
What does everybody think?

I'm not a huge contributor, but I follow along and contribute when I can. However, I have been using Storybook professionally for a while and can say that this is nothing new. Storybook ALWAYS has breaking changes. I would recommend pivoting a new direction, or just keeping the outdated version. Unless V7 does something we really want to take advantage of.

Well yes - kind of agree with @jpwallace22 - storybook as for the moment have a feeling of most unreliable dependency out there - almos each update breaks something.
I'd try to lean forwad docsaurus or something similar in case it will allow us to preserve project structure (previously docosaurus dictated all the docs to be in specific subfolder to work) since we anyways have to update all the docs - it might be a good point to change the docs engine.


Anaconda Repo Nexus Proxy

DSVMs within Guacamole are currently deployed with anaconda although have no access to the anaconda repo for package management,
Currently conda install commands fail as they are trying to get the packages via https://repo.anaconda.com/ rather than a configured proxy.
To amend this:

[x]  Nexus needs configuring to proxy https://repo.anaconda.com/
[x] Guacamole user resources need to configure the proxy on initial boot.

Can this be assigned to me

Branch merged - issue can be closed


fix issue with status

reverted this code back to the original and just added admin flag in existing places with other flags

cancelling this PR


(GitHub Files Filter) Feature request: invert select with Ctrl+click

Greetings @Mottie 🙂
Currently, 'GitHub Files Filter', only hides the files matching the activated filters.
My suggestion is to also be able to invert select, i.e. only show the matching files, e.g. with Ctrl+click.
For example, in your repo, when Ctrl+clicking MD:

to only display .md files, i.e. to strikethrough the rest filters.
And, if you keep Ctrl+clicking, e.g. also Ctrl+click «dot files»
to only display .md and dot files .
I hope you like my suggestion !

Hi @darkred!
I'll see what I can do... what happens when someone Ctrl+clicks on the «ALL» button?

what happens when someone Ctrl+clicks on the «ALL» button?

Currently, clicking on the «ALL» button disables all filters, i.e. displays all files.
IMHO Ctrl+clicking should have the exact same behavior, i.e. show all files -- hiding all files serves no purpose.

Also, upon further consideration, I believe that the best way to implement would be
not to use Ctrl+click but to add an extra toggle button instead, entitled "Invert", that, when enabled, would make the filters work inverted (display instead of hide).
This way, using Ctrl with clicks would become unneeded - just plain clicking would be enough.
Otherwise, here is a case where the result would be confusing:
Suppose that I have Ctrl+clicked MD to show only .md files:
this means that MD would get a dark background, but its text won't have strikethrough.
What if now (by mistake or not) I press a plain click on JS, to hide already-hidden .js files?
Then the script should automatically first disable the invert MD and then enable the normal JS filter.

And, another suggestion, please, regarding the «ALL» button:
when you press it, all the filters to become disabled, i.e. even after reloading the page (F5).
Currently, their status remains until you manually disable each one,
and that causes confusion for me.

Hmm, now that I read all that again, I'm confused 🤣
So what if I add a new button named "toggle"? Clicking it will invert the filters. So if you only want to see the files ending with "js", you click on that button (which hides the js files), then hit the invert and then only the "js" files are visible.
Then I can store the selected filters in local storage so the next time you return to any PR files, only those filters will be enabled... hmm, I guess it'd have to be stored by PR number because not every PR will have the same file extensions being modified.
And I'm still not sure what you are describing that needs changing for the «ALL» button.

First, of all, sorry for the confusion and for not being consistent to my suggestion description.. 😟
Hoping to clarify everything with my reply below...

So what if I add a new button named "toggle"? Clicking it will invert the filters. So if you only want to see the files ending with "js", you click on that button (which hides the js files), then hit the invert and then only the "js" files are visible.

Yes, exactly.

Then I can store the selected filters in local storage so the next time you return to any PR files, only those filters will be enabled... hmm, I guess it'd have to be stored by PR number because not every PR will have the same file extensions being modified.

Yes, I think that's the best approach.

And I'm still not sure what you are describing that needs changing for the «ALL» button.

Currently, when you enable a filter, e.g. "JS", and so .js files are hidden, the status of that "JS" filter (=enabled) remains after you reload the page (F5).
But, if you press "ALL", then the "JS" filter becomes only temporarily disabled, i.e. the "JS" filter becomes enabled again, after you reload the page.
My suggestion is when you press "ALL", the 'all-filters-are-now-disabled' status to remain after page reload.

Something last, please:
it would be great if afterwards, you also added this new "Toggle" button
and strikethrough applied hiding filter names (from my PR here: https://github.com/Mottie/GitHub-userscripts/pull/68 )
to your other script, "GitHub Diff Files Filter", too.

One more thing, please:
I believe that the default action of the script should be "show matching"(=filter),
not "hide matching"(=filter out).
I understand that you've written the script in order to be able to hide the non-important filetypes from the listings, but I find that it's more suitable to the script's title, 'GitHub Files Filter', if it had:

normal action: "show matching"
INVERT action: "hide matching"

Here is a summary of my suggestions:

add a new button named TOGGLE :

clicking it will invert the filters
normal action: "show matching" / INVERT action: "hide matching"
(regarding the ALL button) the 'all-filters-are-now-disabled' status to remain after page reload
maintain the strikethrough on applied hiding filter names from my PR #68

apply the above to your other script, "GitHub Diff Files Filter".

Yes, thanks! Sorry, I've been busy job hunting. Hopefully, everything will be settled soon and I'll have some free time to take care of this.
I was actually thinking of replacing the ALL button with the TOGGLE action.

No problem! I wish you every success ! 👍

I was actually thinking of replacing the ALL button with the TOGGLE action.

Great idea!

Busy weekend. I didn't forget about you, I just didn't get around to working on this script. It's high on my list now 😸

Ok try out this script; if it works like you want, I'll go ahead and commit it:

Files-filter

// ==UserScript==
// @name        GitHub Files Filter
// @version     1.2.0
// @description A userscript that adds filters that toggle the view of repo files by extension
// @license     MIT
// @author      Rob Garrison
// @namespace   https://github.com/Mottie
// @include     https://github.com/*
// @run-at      document-idle
// @grant       GM_getValue
// @grant       GM_setValue
// @grant       GM_addStyle
// @require     https://greasyfork.org/scripts/28721-mutations/code/mutations.js?version=666427
// @icon        https://github.githubassets.com/pinned-octocat.svg
// @updateURL   https://raw.githubusercontent.com/Mottie/GitHub-userscripts/master/github-files-filter.user.js
// @downloadURL https://raw.githubusercontent.com/Mottie/GitHub-userscripts/master/github-files-filter.user.js
// ==/UserScript==
(() => {
	"use strict";

	// Emphasize selected buttons, disable hover when all selected and remove
	// animation delay; See #46
	GM_addStyle(`
		.gff-filter .btn.selected { font-variant: small-caps; }
		.gff-filter .btn:not(.selected):not(:first-child) {
			text-decoration: line-through;
		}
		.gff-filter .gff-all:not(.selected):focus,
		.gff-filter .gff-all:not(.selected) ~ .btn:focus,
		.gff-filter .gff-all:not(.selected) ~ .btn.selected:focus,
		.gff-filter .gff-all:not(.selected):hover,
		.gff-filter .gff-all:not(.selected) ~ .btn:hover,
		.gff-filter .gff-all:not(.selected) ~ .btn.selected:hover {
			border-color: #777 !important;
		}
		.gff-filter .btn:before, .gff-filter .btn:after {
			animation-delay: unset !important;
			filter: invert(10%);
		}
	`);

	let settings,
		inverted = [],
		list = {};
	const types = {
			// including ":" in key since it isn't allowed in a file name
			":all": {
				// return false to prevent adding files under this type
				is: () => false,
				text: "\u00ABtoggle\u00BB"
			},
			":noExt": {
				is: name => !/\./.test(name),
				text: "\u00ABno-ext\u00BB"
			},
			":dot": {
				// this will include ".travis.yml"... should we add to "yml" instead?
				is: name => /^\./.test(name),
				text: "\u00ABdot-files\u00BB"
			},
			":min": {
				is: name => /\.min\./.test(name),
				text: "\u00ABmin\u00BB"
			}
		},
		// TODO: add toggle for submodule and dot-folders
		folderIconClasses = [
			".octicon-file-directory",
			".octicon-file-symlink-directory",
			".octicon-file-submodule"
		].join(",");

	// default to all file types visible; remember settings between sessions
	list[":all"] = true; // list gets cleared in buildList function
	settings = GM_getValue("gff-filter-settings", list);

	function updateFilter(event) {
		event.preventDefault();
		event.stopPropagation();
		const el = event.target;
		toggleBlocks(
			el.getAttribute("data-ext"),
			el.classList.contains("selected") ? "hide" : "show",
			event.ctrlKey
		);
	}

	function updateSettings(name, mode) {
		settings[name] = mode === "show";
		GM_setValue("gff-filter-settings", settings);
	}

	function toggleImagePreview(ext, mode) {
		if ($(".ghip-image-previews")) {
			let selector = "a",
				hasType = types[ext];
			if (!hasType) {
				selector += `[href$="${ext}"]`;
			}
			$$(`.ghip-image-previews ${selector}`).forEach(el => {
				if (!$(".ghip-folder, .ghip-up-tree", el)) {
					if (hasType && ext !== ":all") {
						// image preview includes the filename
						let elm = $(".ghip-file-name", el);
						if (elm && !hasType.is(elm.textContent)) {
							return;
						}
					}
					el.style.display = mode === "show" ? "" : "none";
				}
			});
		}
	}

	function toggleRow(el, mode) {
		const row = el.closest("tr.js-navigation-item");
		// don't toggle folders
		if (row && !$(folderIconClasses, row)) {
			let state;
			if (mode) {
				state = mode === "show" ? "" : "none";
			} else {
				// toggle
				state = row.style.display === "none" ? "" : "none";
			}
			row.style.display = state;
		}
	}

	function toggleAll() {
		const files = $(".file-wrap");
		// Toggle all blocks
		$$("td.content .js-navigation-open", files).forEach(el => {
			toggleRow(el);
		});
		// update filter buttons
		$$(".gff-filter .btn", files).forEach(el => {
			el.classList.toggle("selected");
		});
	}

	function toggleFilter(filter, mode) {
		const files = $(".file-wrap"),
			elm = $(`.gff-filter .btn[data-ext="${filter}"]`, files);
		/* list[filter] contains an array of file names */
		list[filter].forEach(name => {
			const el = $(`a[title="${name}"]`, files);
			if (el) {
				toggleRow(el, mode);
			}
		});
		if (elm) {
			elm.classList.toggle("selected", mode === "show");
		}
		updateSettings(filter, mode);
	}

	function toggleBlocks(filter, mode) {
		if (filter === ":all") {
			toggleAll();
		} else if (list[filter]) {
			toggleFilter(filter, mode);
		}
		// update view for github-image-preview.user.js
		toggleImagePreview(filter, mode);
	}

	function addExt(ext, txt) {
		if (ext) {
			if (!list[ext]) {
				list[ext] = [];
			}
			list[ext].push(txt);
		}
	}

	function buildList() {
		list = {};
		Object.keys(types).forEach(item => {
			if (item !== ":all") {
				list[item] = [];
			}
		});
		// get all files
		$$("table.files tr.js-navigation-item").forEach(file => {
			if ($("td.icon .octicon-file", file)) {
				let ext, parts, sub,
					link = $("td.content .js-navigation-open", file),
					txt = (link.title || link.textContent || "").trim(),
					name = txt.split("/").slice(-1)[0];
				// test extension types; fallback to regex extraction
				ext = Object.keys(types).find(item => {
					return types[item].is(name);
				}) || /[^./\\]*$/.exec(name)[0];
				parts = name.split(".");
				if (!ext.startsWith(":") && parts.length > 2 && parts[0] !== "") {
					sub = parts.slice(0, -1).join(".");
					// Prevent version numbers & "vs. " from adding a filter button
					// See https://github.com/tpn/pdfs
					if (!/[()]/.test(sub) && !/[\b\w]\.[\b\d]/.test(sub)) {
						addExt(ext, txt);
						ext = parts.slice(-2).join(".");
					}
				}
				addExt(ext, txt);
			}
		});
	}

	function sortList() {
		return Object.keys(list).sort((a, b) => {
			// move ":" filters to the beginning, then sort the rest of the
			// extensions; test on https://github.com/rbsec/sslscan, where
			// the ".1" extension *was* appearing between ":" filters
			if (a[0] === ":") {
				return -1;
			}
			if (b[0] === ":") {
				return 1;
			}
			return a > b;
		});
	}

	function makeFilter() {
		let filters = 0;
		// get length, but don't count empty arrays
		Object.keys(list).forEach(ext => {
			filters += list[ext].length > 0 ? 1 : 0;
		});
		// Don't bother if only one extension is found
		const files = $(".file-wrap");
		if (files && filters > 1) {
			filters = $(".gff-filter-wrapper");
			if (!filters) {
				filters = document.createElement("div");
				// "commitinfo" allows GitHub-Dark styling
				filters.className = "gff-filter-wrapper commitinfo";
				filters.style = "padding:3px 5px 2px;border-bottom:1px solid #eaecef";
				files.insertBefore(filters, files.firstChild);
			}
			fixWidth();
			buildHTML();
			applyInitSettings();
		}
	}

	function buildButton(name, label, ext, text) {
		return `<button type="button" ` +
			`class="btn btn-sm selected BtnGroup-item tooltipped tooltipped-n` +
			(name ? name : "") + ` gff-btn" ` +
			`data-ext="${ext}" aria-label="${label}">${text}</button>`;
	}

	function buildHTML() {
		let len,
			html = `<div class="BtnGroup gff-filter">` +
				// add a filter "all" button to the beginning
				buildButton(" gff-all", "Toggle all files", ":all", types[":all"].text);
		sortList().forEach(ext => {
			len = list[ext].length;
			if (len) {
				html += buildButton("", len, ext, types[ext] && types[ext].text || ext);
			}
		});
		// prepend filter buttons
		$(".gff-filter-wrapper").innerHTML = html + "</div>";
	}

	function getWidth(el) {
		return parseFloat(window.getComputedStyle(el).width);
	}

	// lock-in the table cell widths, or the navigation up link jumps when you
	// hide all files... using percentages in case someone is using GitHub wide
	function fixWidth() {
		let group, width,
			html = "",
			table = $("table.files"),
			tableWidth = getWidth(table),
			cells = $$("tbody:last-child tr:last-child td", table);
		if (table && cells.length > 1 && !$("colgroup", table)) {
			group = document.createElement("colgroup");
			table.insertBefore(group, table.childNodes[0]);
			cells.forEach(el => {
				// keep two decimal point accuracy
				width = parseInt(getWidth(el) / tableWidth * 1e4, 10) / 100;
				html += `<col style="width:${width}%">`;
			});
			group.innerHTML = html;
		}
	}

	function applyInitSettings() {
		Object.keys(list).forEach(name => {
			if (settings[name] === false) {
				toggleBlocks(name, "hide");
			}
		});
	}

	function init() {
		if ($("table.files")) {
			buildList();
			makeFilter();
		}
	}

	function $(str, el) {
		return (el || document).querySelector(str);
	}

	function $$(str, el) {
		return Array.from((el || document).querySelectorAll(str));
	}

	document.addEventListener("click", e => {
		if (e.target.classList.contains("gff-btn")) {
			updateFilter(e);
		}
	});

	document.addEventListener("ghmo:container", () => {
		// init after a short delay to allow rendering of file list
		setTimeout(() => {
			init();
		}, 200);
	});
	init();

})();

Thanks a lot for your effort! 👍

Unfortunately though, the new version doesn't do anything: no filter buttons group, no filtering, nothing.
And there's no error in browser's Console.
I've tried both latest Tampermonkey versions (TM 4.8.41 stable and TM 4.9.5971 beta)
in a fresh Chrome 76/Firefox 69 profile with only the script installed, in e.g.
https://github.com/Mottie/GitHub-userscripts and
https://github.com/darkred/Userscripts

Hmm, you mentioned this before:

normal action: "show matching" / INVERT action: "hide matching"

To me that is essentially what the toggle button does now; it inverts the selected state of all the buttons instead of the button action (matching). The results are the same - unless I'm utterly over-thinking this whole thing.

The results are the same - unless I'm utterly over-thinking this whole thing.

Unfortunately I have to disagree with you. 😟
The current implementation of "Toggle" just switches the status of each filter.
Yes, I had agreed with you here on that, but as I test your new version,
there's a case in which I find it unpractical: that is when "Toggle" and all filters are all disabled,
i.e. when I click a filter for the first time.
What was my original idea, and end up again, is, with "Toggle" and all filters disabled, as I INITIALLY click a filter, the OTHERS to become disabled, not the one I click. That's the ideal implementation I can think of "show matching", i.e. as I choose a filter, to display only the matching filetypes for that filter - not to always have in mind which filters I don't want at that time, to disable.
So, I suggest that in order to also cover the case above, the functionality should be modified as follows:

Suppose that you are in https://github.com/Mottie/GitHub-userscripts and "Toggle" and all filters are all disabled.
As I click the first filter, "DOT-FILES", what should change is the other filters: NO-EXT, MD, JS, USER.JS, JSON, to become enabled, i.e. to hide all filetypes other than dot-files.
If then I also click the second filter, "NO-EXT", then it would switch to disabled, and it would just also display no-ext files along with dot-files, and so on..
If, at some point I enable "Toggle", then to switch the status of each filter,
and as I click a filter, to switch its status. (i.e. as it currently works).

Two more suggestions regarding the «Toggle» button :

change its tooltip as: Toggle filters status. I find it more suitable.
to move it to the end of the buttons (maybe with an additional separator between it and the last filter button), to be less distracting.

Sorry for changing my mind once more, but I've been thinking over my last suggestion a lot,
and I end up that it would be counterintuitive, when you initially single/plain click on a filter,
the other filters to become disabled.
So, my final suggestion is that, the new «Toggle» button is useful as it is, so keep it (changing its tooltip and moving it to thend),
and that, it would be convenient if you also added a keyboard shortcut, e.g. Ctrl+click,
so that, what ever might be the filters current status,
as you Ctrl+click on a filter, the others to become disabled,
and as you keep on Ctrl+clicking filters to show more matching filetypes.

If I may facilitate you a bit, here are the few changes for my last suggestion that I managed to make:

(change button name) change line 50 to:

text: "\u00ABInvert\u00BB"

(change button tooltip) change line 259 to:

buildButton(" gff-all", "Invert filters status", ":all", types[":all"].text);

(detect Ctrl+Click) lines lines 317-321 to:

document.addEventListener("click", e => {
	if( e.target.classList.contains("gff-btn")) {
		if ( !event.ctrlKey ) {		// plain click
			updateFilter(e);
		} else {					// Ctrl+click
			showOnlyFilter(e);		// New function
		}
	}
});

Now, what's left to be done  (sorry I can't contribute more) :

The Invert button to appear to the end of the filers.
(Note: if I change line 266 into the following, then the buttons don't work: )
html = buildButton("", len, ext, types[ext] && types[ext].text || ext) + html;

Make a new function showOnlyFilter(e) that:

whatever might be the filters current status,
as you Ctrl+click on a filter, the others to become disabled,
and as you keep on Ctrl+clicking filters to show more matching filetypes.

I just updated the files filter userscript.
I didn't:

Move the invert button to the right.  I like it on the left - and I changed the icon.
Add a method to allow you to continue to use Ctrl + click. I mean, when you use it, it enables the selected filter and disables all the others. Continuing to use Ctrl + click will continue this behavior. To enable more file types, use a plain click.

Thank you so much!! It's great! 👍


DateTime.UtcNow serialization length varies

From the docs:
Range queries with DateTime strings as filters are only supported if the DateTime strings are all in UTC and the same length.

We use DateTime.UtcNow in code to store DateTimes in cosmos. I do notice however, that the length of the serialized string is not consistent. The ms part is not always 7 positions long, eg:
"responsetime": "2022-08-18T10:13:31.8412666Z",
"resulttime": "2022-08-18T11:14:55.45927Z",

When I take this difference into account and read your docs about "the same length", I get confused.
Question: Can we use DateTime.UtcNow to store DateTimes to cosmos, or do we need something like .ToString("yyyy-MM-ddThh:mm:ss.fffffffZ") to force a consistent string length?

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: c256dbf4-122d-1569-c4c3-0e401766c712
Version Independent ID: 747c3f05-167d-2048-6f1b-fa1d7d856f66
Content: Working with dates in Azure Cosmos DB
Content Source: articles/cosmos-db/nosql/query/working-with-dates.md
Service: cosmos-db
Sub-service: nosql
GitHub Login: @seesharprun
Microsoft Alias: sidandrews

@tomkuijsten
Thanks for your feedback! We will investigate and update as appropriate.

@tomkuijsten, you are right that DateTime.ToString() does not always provide the same consistent number of digits for the millisecond portion of the time.
We will update the doc to remove the mention that the time is always the same length.

@seesharprun thanks for the update. To make this very clear (also for future readers), the amount of ms precision doesn't influence the indexing of the property in cosmos as a datetime, correct? Eg if I store a string as 2022-08-18T10:13:31.1234567Z and another as 2022-08-18T11:14:55.1Z they both get indexed as a datetime and both work in a range query.

My understanding is that this is accurate, but I want to double check with a colleague. Hang tight.

I just got validation that the datetime stored as a string will work in a range query. The range type of index is the default type for any string or number property.


close menu

how do i close the menu and open it back up, also how can i use the stuff ingame cus my mouse locks

Insert and hold alt

how do i use the menu in game also? because when i join into a game i cant move my mouse


Online mode

It doesn' t work with online-mode set to true.

Ok, i don't know how, but it started working fine.


A question about version

excuse me, I'm a fresh here.
want to know why ramda does not have version 1.0.0? and when come to version 1.0.0?

Yep the lib is still actively being maintained. I'll close this and keep https://github.com/ramda/ramda/issues/3468 open for tracking 1.0.0 release


ServerInfo and OrphanProcessMonitordeprecation

ServerInfo and OrphanProcessMonitor classes are going to be removed eventually from splunktalib. solnlib's version should be used.

#37 introduces depreciation of those classes.