text:
Google tag manager or before/after body head opens/closes

Is this a bug report?
Not a bug, but a suggestion
Have you read the [Contributing Guidelines on issues]?
Multiple times.
Feedback and suggestion
Okay, please keep in mind, I am a developer, but not a JS developer, and obviously not a React developer too. I don't know the best ways to do stuff in the space, but want to provide some feedback.
First, I really think Docusaurus is very cool! Kudos!
Okay, I have been trying to integrate about four different sets of JS analytics tags into my site, and have come back with some observations and an enhancement suggestion.
Most tag providers generally suggest that you inline their JS and/or HTML snippets in one of four places:
after the <head>, <body> tags, or before the </head>, </body> tags.
They don't generally suggest putting these tags in a separate mytagsnippets.js files, from my recent experience.
While putting these tags in a file such as mytagsnippets.js certainly works, there are differing opinions on whether that could be sub-optimal in a sufficient number of cases due to potential multiple Http requests, etc.   https://stackoverflow.com/questions/3870345/new-google-analytics-code-into-external-file
I don't want to start a discussion about that topic, for sure.
But for those who do think that inlined JS is worth is, and it seems most JS tag suppliers do recommend this method, I do want to ask the question, does the Docusaurus team want to support that more directly?
I did want to follow the recommendations of the SO pundits, and my own HTTP experience and keep the JS inline, even though the file would be cached, etc, etc, etc.
But I found this very difficult to for a couple reasons, 1) it is tough to identify how/where to edit the JS/React to insert HTML, or <Script> stuff at the four locations mentioned earlier. 2) I am currently in blog mode, which makes it even harder (can't hack some JS).
I also didn't want to get into hacking stuff lib/*.js for obvious reasons.
I would suggest these two possibilities for help poor non-front end persons such as myself:
A) Consider allowing straight HTML insertion into the four places I suggested, which would allow the JS and HTML dual combos used by modern analytics platforms such as Facebook and Google.
B) Consider directly supporting Google Tag Manager like how you did with Google Analytics. (No, I don't work for Google.)
Option B) would allow non-web developer like myself to really really easily deal with two or more sets of tag snippets if we are using Google's Tag manager.
Option A) would allow non-web developer like myself to just drop in the HTML & JS in the right place if we felt we should follow the directions of the tag providers to the letter.
Keep in mind some users of Docusaurus may not be able to evaluate the impact between following the suggested method of inlining JS+HTML tags vs dropping it into a JS file to be referenced by the siteConfig/scripts variable. They may not understand it is mostly equivalent, and not too problematic except in a small fractional number of cases.
I ultimately ended up using a feature of Netlify called 'Snippet injection' cause I was really struggling to find good way to do this with Docusaurus.
Thanks again for creating Docusaurus.
Cameron

Thank you @cameron-elliott for the suggestion. To be honest, I found it hard as well when I first started to use & contribute to Docusaurus given that I have not much experience for web development.
In the current state, it is indeed true that it is tough to identify how/where to edit the JS/React to insert HTML, or

@endiliey - Would you consider a solution for V1? I manage several docmentation site built with Docusaurus V1 and I need to integrate with Google Tag Manager.
I could probably use an external script to add code snippets provided by Google Tag Manager but I don't think that is helpful. The tag manager should be loaded as soon as possible. The following quick start guide shows that there two places  where scripts needs to be added (one is immediately after opening <head> and another is immediately after opening <body>).
https://developers.google.com/tag-manager/quickstart
For V1, this could be a simple configuration in siteConfig.js which accepts the "tag manager ID". and Docusaurus can generate with the site with the necessary scripts added in the right places.
For V2, I think we will need a plugin like this one with more advanced capability:
https://www.gatsbyjs.org/packages/gatsby-plugin-google-tagmanager/
I'd be happy to open a PR for the V1. I will not be able to migrate to V2 any time soon since it's still in alpha stage and a lot of doc specific feature is not setup yet (i.e. versioning as far as I know). Others may be in similar situation as well. But In the meantime, I need to integrate with Google Tag Manager and I'd prefer having it setup properly instead of hacking around it.
Thoughts?

Sorry but v1 is in maintenance mode now.

Sorry but v1 is in maintenance mode now.

I guess it's your call as the maintainer of Docusaurus but isn't it a bit too early since V2 is still in alpha stage?
Unfortunately the workaround is a little too heavy. My only option (as far as I can think of) is:

Introduce a custom post-build process that will go through every html files generated and insert the necessary script blocks for google tag manager. This is too much work.
Use an external script to add google tag manager during runtime when the site is launched. This will delay the setup and can probably skew the results in analytics (i.e. user left the site or browsed to another page before the analytics could be setup)

My suggestion above was to allow us to be able to plugin google tag manager id in the siteconfig similar to google analytics config that is already available. It's not a huge change.
I hope you'll reconsider @endiliey. This would really help out a lot. I can open up a new PR if you agree. Please let me know.

I guess it's your call as the maintainer of Docusaurus but isn't it a bit too early since V2 is still in alpha stage?

I'll be honest here. The more we add up feature to v1, the more it introduces more work for us to backport it to v2. It's also two completely different codebase. Reviewing takes time. And this is not just a matter of huge change/ not. The moment we accept new feature request, people will keep requesting new feature or sending new feature in. Well, most open source project out there usually can just ignore issues and PRs, but I personally am happier to respond to each of them rather than ignoring it. (that's why docusaurus has < 50 issues open and PRs are generally responded quite fast compared to other project).
Another reason is because v2 has matured. We have 100+ known public GitHub users right now and 2,6k+ downloads/week for v2 (lot of our user use it for internal setup), and we want to focus on that. Lot of features parity has been matched, and probably what's left for beta is docs versioning and translation. Beta will have full release features.
I hope you understand. Some recommendation: fork or use https://www.npmjs.com/package/patch-package. It's OSS afterall.

I understand. Thanks for all of your time and effort. It's a great tool for getting up and running with Documentation easily.

authors: cameron-elliott endiliey parvezakkas


text:
fix(theme-classic): disable text-transform of codes in admonition titles

Motivation

Currently text-transform: uppercase is set for .admonition h5. This makes all texts uppercased even when wrapped by <code />.
:::tip This is a `code`
:::

Have you read the Contributing Guidelines on pull requests?

Yes
Test Plan

After changes are made, codes are no longer uppercased as shown in the screenshot below.

seems reasonable 👍

source: gharchive/pull-request

authors: chelproc slorber

repo: facebook/docusaurus

license: MIT

license_type: permissive

license_source: github-api


text:
Implement a Webpack loader

We use webpack for transforming JSX to JS, dependency management, and concatenation.  It would be lovely if Flow was callable as a Webpack loader:
    {
      "test":   /\.jsx?$/,
      "loader": "react-hot-loader!flow-loader!jsx-loader?harmony"
    },

@appsforartists Did you manage to find a good solution for this? flowcheck-loader works up to a point but fails with some advanced features (stage 1 decorators etc.).

@appsforartists I figured out a workaround. You can try something like loaders: ['react-hot', 'babel', 'flowcheck', 'babel?stage=0&blacklist=flow']. See https://github.com/gcanti/flowcheck/issues/19 for further discussion.

Any update on a flow pre-loader?

@breandr Check out babel-plugin-typecheck. I feel that's a better alternative than flowcheck right now.

I just dump babel results to disk before my packager gets started, in a build directory.  There's really no need for these preloaders and adapters.

@bebraw Plus I'm guessing that flowcheck would slow down my app at least as much as React PropType checks (which come out at the top of my profiling results and make some mouse drag interactions laggy due to the complexity of my app).  So I'd rather just stick with compile-time checks right now.

@jedwards1211 Flow is surprisingly fast in daemon mode actually. But yeah, even something like babel-plugin-typecheck is quite nice even if it's not exactly the same.

@bebraw yes Flow is fast, but it has nothing to do with flowcheck does it?  As far as I understand flowcheck just runs JS code injected into your app to validate at runtime, rather than interacting with a Flow daemon in any way.  It's the runtime validation I'd expect to be slow, not the compile-time checks that Flow does.

@jedwards1211 Correct. The runtime checks are pretty much equal to what you get with propTypes as far as I understand. It just generates some runtime asserts there. So it's nowhere near the same, but far better than nothing.

any flowtype webpack integration to see flow status results in webpack output ?

please don't use github tickets for tech support

It's at least possible to create a webpack plugin that execs flow status every time something is recompiled...I'll probably do that at some point if no one else does

@jedwards1211 That's the sort of thing I came here looking for. At the moment I'm using eslint-loader for webpack to lint my code every time I change something. It would be awesome to integrate flowtype into that workflow, and see the output of flow status whenever webpack detects a change.

Oh wait, I just found flow-status-webpack-plugin: npm | github

It figures someone would have done that by now -- thanks for pointing that out!

@camjackson heh...I tried it but I don't always see the flow status output, and there is no github or issues link in that npm package, which is the only thing its author has published to npm.  I guess I'll e-mail him...

@jedwards1211 Yeah it's annoying when npm doesn't link to github. I managed to find it though if you want to open an issue: https://github.com/diegodurli/flow-status-webpack-plugin

@camjackson I did and made a fork; warning!! I would recommend using my fork until my PR gets merged, mainly because the FlowStatusPlugin constructor in the public package has the surprising side effect of restarting flow.

@jedwards1211 As far as I can tell that plugin won't fail the webpack build if there are flow errors? Is there a plugin that can do that? I thought that would be the whole point of a webpack plugin for flow :D

@moljac024 right, it doesn't fail the build, which would be helpful.
As an aside, these days instead of using that plugin I just use a separate swatch script (though I haven't figured out how to get it to preserve formatting and font weight):
#!/bin/bash
which wr || npm i -g wr
flow status
wr --exec "clear && printf '\e[3J'; flow status" src test

I have implemented a basic version of the flow webpack plugin, that fails the build on errors. You can find it at my fork, which isn't merged upstream yet.

Meanwhile I decided to implement a true [pre]-loader that calls flow check-contents individually for each file matched and aborts on error.
$ npm install --save-dev flow-bin flow-bin-loader

module.exports = {
  // ...
  module: {
    preLoaders: [
      // ...
      {
        test: /\.js$/,
        loader: 'flow-bin',
        exclude: /node_modules/,
      },
      // ...
    ]
  },
  // ...
}

The implementation is straightforward enough to fit here:
const spawn = require('child_process').spawn;

module.exports = function(source, map) {
  const cb = this.async();
  const flow = spawn(require('flow-bin'), ['check-contents']);

  let stdout = '';
  flow.stdout.on('data', (data) => {
    stdout += data;
  });

  flow.on('close', (code) => {
    if(code)
      console.log(stdout.replace(/^-(:[0-9]+.*)/, `${this.resourcePath}$1`));

    cb(code ? code : null, source, map);
  });

  flow.stdin.write(source)
  flow.stdin.end();
};

Still no loader available for flow with webpack ?

@bboysathish did you try https://www.npmjs.com/package/flow-bin-loader?

source: gharchive/issue

authors: StoneCypher appsforartists artyomtrityak bboysathish bebraw breandr brunocodutra camjackson jedwards1211 moljac024

repo: facebook/flow


text:
readme.md should be more focused on installing & usage.

I've decided to finally add Flow to our dev stack on the project I am currently working on. I had a bit of trouble getting started though, as I was a bit surprised that the first thing I saw in the readme is how to build Flow instead of how to actually install it and get up & running.
For me personally it was quiet stressful as I wasn't sure if I need to do the building or I can just install using brew (I'm pretty sure there's a diagnose for that).
I am not very good at writing stuff so just take this as a poke & point to the better (didn't want to use "right") direction.
Thanks,
Foxhoundn

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

This seems like a good idea! Thanks for the contribution!

@facebook-github-bot import

Thanks for importing. If you are an FB employee go to Phabricator to review.

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!


text:
Add silence support.

With this patch there is a new section in .flowconfig:
[silence]
/path/to/file.js
/path/to/dir

Paths in [silence] will still be typechecked, but any
errors will be silenced as if there was a suppress_comment comment string
on every line where there are errors.
I called it silence to make it stand out from ignore and suppress_comment as
it currently silences all errors, including lints.
I believe this fixes https://github.com/facebook/flow/issues/869, though I admit I didn't read
the whole issue.
(If this is accepted I'll add docs in a follow-up).

Note that I have never written OCaml before...let me know if there is anything I can do better.

I'm curious to see how this will be received by the flow team.
All for suppressing flow errors internal to dependencies, while also checking against the API.

Test failure is legit...apparently make test doesn't run make js. I'l fix it tonight.

Open questions:

Should we accept regexes instead of paths?
Should we throw a warning when a file is silenced but there are no problems in the file to silence?
Should we to silence node_modules by default?

Should we accept regexes instead of paths?

I would follow whatever [ignore] does.

Should we throw a warning when a file is silenced but there are no problems in the file to silence?

I agree, silent means silent.

Should we to silence node_modules by default?

Not at first. Let people get used to [silence]. Then down the road it can be a default.

Silencing node_modules will fix the spam which has been putting me off from using flow - Looking forward to the merge, thanks @LegNeato

👉 @gabelevi

Has anyone looked at this in the last week?

+1 for this

I don't think broken types should implicitly works and hide errors. It's like knowing there's a problem with your health but don't care about it. And one day you will die. Who cares?

Don't shoot in your feet, guys.

@TrySound That depends on your definition of "broken". If your project contains a dependency that is using older versions of flow (which is a common scenario), your project's flow version might consider that dependency's typings to be broken. However, they are still perfectly valid for the flow version used by the dependency and can be safely silenced.

[untyped] safely treats it as any without hiding dangerous errors

@TrySound [untyped] would also ignore any types that WERE working, why would you EVER want to do that???
I just need to silence errors in node_modules that I have ZERO control over.  If flow can get types and help me with the rest of the library I want that, hence [silence].  Give me the help, don't break my build because of errors which I can not control though...

@TrySound What I (and I think many others) really want is for Flow to verify our use of 3rd party APIs, but not to make us responsible for 3rd party internals. [untyped] and [ignore] fails to do the former. Doing nothing does the latter. [silence] hits the sweet spot, insofar as it is possible.

+1000 for merging this.

@TrySound your thumbs down tells me that you really don't care about other peoples needs and only your own.  How is that helpful in the open source community?

I just think that hiding errors is nonsense which will lead community to really bad feel about flow correctness.

@TrySound you are literally arguing that ignoring typing is better than silencing an error.  Silencing an error still allows flow to do its job, it merely silences SPECIFIC CHOSEN errors that we can NOT control.  Your suggestion goes a step further and completely ignores the typing.  How does one make the community feel worse than the other?  In both cases you are ignoring an error, you are merely going about it differently.  Your chosen path goes WAY further than merely silencing and in effect renders flow useless.  Want the community to have a negative view, render your library useless...

Why is this taking so long?  Someone already did the work, the community has been very patient.  I'm still not using flow because of this missing necessity, but I'd really like to!

How many weeks will I keep checking back for this before I give up on flow and just recommend typescript to my team?  I'm starting to wonder.

@jlaustill This doubtful change is not critical for using flow.

@TrySound yes it is, so I will just go to typescript

Good luck

@TrySound Why would you prefer to disable type checking the public APIs of dependencies, when they only have type issues internally? Is that an unfair reading of your position? I just can't understand it.
Wouldn't using [silence] be equivalent to what happens when typings for a library are maintained externally?
This is getting very repetitive at this point, but I don't know what else to say: there is value in knowing that I've misused an API regardless of whether their flow annotations internally are correct. It seems ideal that we'd get errors initially, report them upstream, and silence them locally so that for example CI can pass in the meantime.

Honestly, I'd like to hear from other devs. I still didn't get if @TrySound is a troll or just very closed-minded

I think other devs are just tired of their requests for silence support falling on deaf ears. This PR is 7 months old and the issue it solves (#869) was first reported 3 years ago.

@Palisand I mean other devs responsible for Flow

I too support this feature, I've tried to add flow to my react native project a couple times, but the inability to hide all the flow issues in dependencies made it nearly impossible to see / manage real issues in my code.

We currently have 371 flow errors in our react-native project.
361 of which are in the node_modules folder.
But 10 are currently in our code. And no one in our team can be bothered to check her flow errors before checking in, because they are so hard to see among the many errors we do not control.
Due to this missing feature flow is now just a warning system in our editors, but not part of the build infrastructure, as it breaks anyway.
Please accept the pull request! So that we can finally move on to type checked code in javascript.

@timLoewel You probably should treat react-native as untyped since it's are broken. This will allow you to run flow on ci.

What's frustrating about that strategy @TrySound is that the externally facing types are not broken. They are simply self-referentially broken. Things like component prop types should still be preserved. [silence] would fix this very nicely.

Exactly!
I would have to throw out half of my type checks, just to not see errors/warnings, I am not interested in.
@TrySound  why do you keep repeating the same argument, that we could use the current configuration options to silence the errors? Do you not listen?
The answer is always the same: We want types! We love types! That is why we use flow.
I was surprised by this, when I started using flow, because the suggested silence solution is the one I was expecting to be the default. This is how many other code verifiers work.
And why do you say, that this was "not critical for using flow"?
If flow can not be used in a build pipeline, because it fails every build is that not critical?
So many users in this thread say, that it is critical for them. Is that not enough proof that it is critical?
This is not about the objective truth. It is about making the tool work for the community.

How many weeks will I keep checking back for this before I give up on flow and just recommend typescript to my team? I'm starting to wonder. @jlaustill

The transition is already starting for our teams. New projects are getting Typescript support from now on. Our decision is motivated by 2 reasons:

node_modules which can't be silenced
Too many breaking changes (which makes silencing node_modules all the more important)

I've been watching this PR for > 6 months and the discussion seems to be going nowhere. I just don't understand why there are backlashes against this feature. A lot of people seem to need it and it wouldn't introduce breaking changes as it's a new config option.

@mrkev Could you please take a look on this PR?

Woah ok, this is a popular and meaty one 😅
I can't really do much here since there's merge conflicts. The diff looks scary because it's so much code, but relatively straightforward. If someone can fix it I can't promise I can get it merged, but I think it's a good addition and will vouch for it 👍

I can rebase. Should be able to get to it a bit later today.

@mrkev Rebased.

@LegNeato amazing!  If this gets merged I will start testing it asap.

Does anyone have a quick test repo that would show why this change is necessary? It'd help.
From what I read node_modules is a big issue, but external dependencies from here by default get imported as any and display no errors. Are people trying to force flow to infer types inside node_modules?

FWIW I posted a bunch of real world use-cases in the task that I hit in a project.

@mrkev As I understand it, files in node_modules that aren't Flow files don't get type-checked and by default get imported as any, but files in node_modules that are Flow files do get checked and are imported as whatever type Flow determines them to be.
It's possible that such a dependency might be written against a version of flow which did not raise any errors, but that the project which is consuming the dependency is using a different version of Flow that does raise errors in the dependency's code. Another possibility is that the dependency used an error suppression comment that is not commonly used, and thus not likely to be set up in any consuming project's .flowconfig; causing known and supressed errors to be unsupressed.
JSON files are still a problem, if they're malformed they will cause a flow error. Since they cannot have pragmas, they're automatically checked. There are some projects that include intentionally malformed JSON files in their tests (in order to ensure specific handling of such files).
In all of these cases, we will get errors that we cannot fix. These errors add noise and negatively impact the developer experience. We can eliminate them by ignoring the problematic files in .flowconfig, but this is sub-optimal, as it causes the ignored file to not be type-checked at all, leading to an implicit any import, or having to create a libdef.
[silence] fixes this by suppressing only the error notification, not the type inference.
I'm on mobile right now and can't create a sample repo, but the config-chain package is one that includes a malformed JSON file. It is depended on by (old?) versions of npm, which are depended on by other packages; one example of which is gitbook-cli. Simply including that package as a devDependency in a Flow project should demonstrate the problem.

@mrkev I just made one quick
git clone https://github.com/jlaustill/flow-needs-silence.git
cd flow-needs-silence
yarn install
flow
You will see one error from immutable inside node_modules.  If node_modules was silenced, problem solved :)

Here are the exact real-world scenarios that caused me to write this patch:

Different flow configuration from third-party libs
Your flow version doesn't match what a lib in node_modules is using for their project. Their types may depend on updated typedefs that ship with flow, causing errors for you but showing clean for them.
Similarly, when there are suppressed errors using suppress_comment in a lib in node_modules and it doesn't match YOUR suppress_comment values you will see errors where they will not.

Fixed flow bugs causing errors
I updated to the latest version of flow, which fixed a flow bug. One of my dependencies has a $FlowFixMe to workaround the bug. I now get an "Error suppressing comment. Unused suppression error" because the bug has been fixed and the suppression is not necessary with my flow version.
The dependency (https://github.com/callemall/material-ui) doesn't get an error with their flow version and can't remove that suppression line if they want to support older versions of flow that other users may have installed.

Built-in typedef and version hell

Started with no flow errors or warnings.

I updated material-ui to get new library features.

The updated material-ui was using flow >= 0.53.0, so its React types didn't match the ones my version of flow (0.51.0) understood. I now had a bunch of type errors due to React type mismatches.

I upgraded my version of flow to >= 0.53.0. The React errors went away as expected, but NEW errors in a subdep of some library I am using popped up due to changed flow behavior (example: https://github.com/cssinjs/jss/pull/580)
So now I have to either fork the whole dep chain to fix the issue, wait for the various libraries to fix, release, and update all their deps, or use yarn's overrides.

Update: busy week this week + short week next week = slow process

@LegNeato A team member involved in this just came back from PTO this week, so this was sort of blocked-- trying to get this reviewed this week though!

@mrkev Thanks for taking the time with @LegNeato 's much-needed work!  I look forward to adding flow back to my projects and giving this a go.

Ok, this seems to be good, albeit one change. Instead of calling it "silenced files" we'd want to call them "declaration files", in line with Hack's decl mode. There currently is no @flow decl, but it's an idea that been played around with, and were it to materialize, it'd be good to have the terms align. 😄

@mrkev Rebased and changed naming.
Wasn't sure grammatically to go with [declaration] (matching include and exclude) or [declarations] (matching libs and lints). Ended up with [declarations], as it isn't a verb like include or exclude.
Also, I noticed the command line option for [libs] is --lib, so I made the command line option for [declarations] be --declaration. Let me know if you'd prefer it to be plural.
Finally, I didn't squash so you can see the changes. I assume you'll do so when you merge. Let me know if you'd rather have them squashed into one commit here in the PR.
Thanks again for pushing this through!

Oh nice, that's what you call quick turnaround 😄 Alright re-importing-- the squash should be no issue.

Failure on AppVeyor looks unrelated:
[00:24:59] [—] FAIL:  lsp\queries                       (10/10 tests. 36 steps passed. 1 steps failed)

Wouldn't suprise me, AppVeyor has been flaky lately.

I got a thumbs up, but it's generally bad practice to merge things late on a Friday. I'll rebase and attempt to land next week 👍

Awesome!
FYI for those of you at Facebook: this was merged (https://github.com/facebook/flow/commit/433581b51b44f345e7ffa9ba8b78487da245d7dc) with references to [silence], but it was changed to [declarations] by the time it was merged, so be aware of that in the next changelog :+1:.

Finally I can give Flow another chance.
@LegNeato thank you!

Aaaaand the Changelog is wrong, it says [silence] (so does the commit message of https://github.com/facebook/flow/commit/433581b51b44f345e7ffa9ba8b78487da245d7dc - but the commited code clearly shows [declarations])
https://github.com/facebook/flow/issues/6572

The changelog is wrong, but it doesn't matter, because [declarations], although it's now a supported config section, doesn't actually work.
I'm running flow 0.76.0. 16 files in node modules don't pass the flow check. One of these files is /Users/kylebebak/Code/Work/919/web/node_modules/npm/node_modules/config-chain/test/broken.json.
None of the following patterns silences flow errors in this file (or any of the other 15 files, for that matter):

/Users/kylebebak/Code/Work/919/web/node_modules/npm/node_modules/config-chain/test/broken\.json
<PROJECT_ROOT>/node_modules/.*
`./node_modules/.

So either the docs are wrong, or the feature was shipped but it's broken.

I confirm that it seems it doesn't work.

I'm digging into this right now, thanks for the reports!

Ok, I think this is a different "issue". This PR (as intended) takes a valid parsed file and suppresses any type errors. It doesn't suppress any parse errors on invalid files (this is what the existing [ignore] section is for).
So, for the case @kylebebak  mentions above [declarations] wouldn't work for config-chain/test/broken.json because it isn't a valid file with type errors, it is invalid json and thus can't be parsed by flow. You need to use [ignore] for those types of issues.
One may think this is bad UX ("why not have an overall "hide any errors in this file?"), but I think it is correct and is the least surprising for your project. They are two fundamentally different types of issues that may affect your project in different ways. There is a big difference between a parse error (flow can't make sense of this file and doesn't know what to do so it is bailing and no types are used) and a type error (flow can make sense of this file and can use types and found an issue). Depending on the particular project merging those two cases into one override could hide correctness issues and cause bugs in production for you. But, the solution is simple...use [ignore] for the former and [declarations] for the latter.
In all my tests with type errors (including @jlaustill's https://github.com/jlaustill/flow-needs-silence.git) [declarations] works as intended. Please open an issue and tag me if you find a case where that doesn't hold.
@kylebebak @gabrielenosso please confirm you are trying to set to [declarations] something that isn't able to be parsed rather than something that is parsed and has type errors.  Please open an issue and tag me if you find a case where type errors are not suppressed.

@LegNeato
You're absolutely right. I ignored the offending node_modules (some were tests, others were written in TypeScript) and now everything passes.
It might be a good idea to include the first paragraph of your comment, which explains things very nicely, as an addendum to the documentation for declarations.
Thanks for getting back to me, and sorry for the false alarm!

@LegNeato first of all, thanks a lot for this great feature ❤
However, it doesn't seem to work for me and I hope it is just me doing something wrong.
These are the steps that illustrate the issue:

Create a new RN 0.55.4 project react-native init FlowDeclarations --version 0.55.4
Install Flow
Run flow
At this point in the new RN project there are 15 Flow errors ( all inside node_modules/react-native/Libraries/).
Add the libraries with Flow errors to .flowconfig's [declarations] section
Run Flow again.

Actual result: The above mentioned Flow errors still stay and are not suppressed. More than that, there are new ones (now there are 47 errors)
Expected result: 15 Flow errors  from the RN Libraries are suppressed, no new errors are added.
I have set up a repo for this use case, you can have a look here.
Am I doing it wrong or it indeed does not work?

@yamov thanks for the repo! I can reproduce the behavior and am looking into it.

Yeah, I'm seeing the same problem as @yamov. They all seem to be type errors coming from react-native-fbsdk and react-native, but the other third-party packages don't seem to be throwing any errors, which is good!

Still digging in, I don't really know OCaml so not sure where to make the fix. Rather than pollute this PR, I filed a new issue for those that want to keep track of the [declarations] fix for flow builtin types:
https://github.com/facebook/flow/issues/6631

I dislike [declarations] name for this option. It does not explain what it really means.
Small poll for option naming:
https://github.com/facebook/flow/issues/6631#issuecomment-411285015

It doesn't suppress any parse errors on invalid files (that is what the existing [ignore] section is for).
Groaaaaaaaaan, so what we need now is

[just STFU about]
.*\.json

@nodkz that's to mimic the fact that probably no one would assume that [ignore] means "act like this file is missing" :trollface:
I agree it's a terrible name.  It's basically saying "these files are type declarations.  Unlike all of my other type declaration files, which are intended for type checking, I'm explicitly declaring these declarations because obviously that means you shouldn't check these declarations"

As stated above, it's meant to align with Hack's decl mode. From the docs:

Decl mode code is not typechecked. However, the signatures of functions, classes, etc in decl mode are extracted, and are used by the typechecker when checking other code. Decl mode is most useful when converting over code written in PHP: although the body of that code might have type errors that you don't want to deal with right away, it's still beneficial to make the signature of that code, or at the very least its mere existence, visible to other code.

That's also the idea behind surfacing parse errors: you can't extract signatures if you can't understand the code. It is purposefully different from [ignore].

@mrkev decl is pure shit title no one understands.
This poll gives you understanding what developers expect it to be called. Changing silence naming was a bad idea. Please stop acting like it's fine just because Hack language named it so.

I'll say it more gently, but I agree with @vladshcherbin. [declarations] sounds an awful lot like [libs] and does not meaningfully describe what it does. It also is confusing given Flow syntax like declare class or declare module.
[silence], while also not perfect due to the existence of [ignore] (which treats the module as completely missing), at least better describes what it does. I'd prefer something even more descriptive like [ignoreErrors].

[flow_fix_me]: *

@mrkev yeah I know, I already saw that, but how is Hack in any way relevant to this?  (not to mention PHP, for goodness sake...)
It seems to me like you guys are so used to its terminology that you have a hard time seeing how confusing this will be to non-Hack users (i.e. most of us, probably).

@mrkev it's also worth mentioning that all .js.flow files can be thought of as "declaration files" even if we want to see errors from them.  "flow-typed declarations" is also a commonly-used term.  And "type declarations" can even live in ordinary .js files.

@mrkev Weighing whether yet another comment is justified, I think it is possibly okay to repeat what I wrote elsewhere, because I pointed out that the naming violates a principle that every programmer is familiar with: information hiding.
In #6572 I wrote:

By the way, when this is documented some day I hope there will also be an explanation for the name "declarations". The previous choice "silence" was more or less obvious to anyone, "declarations" requires internal knowledge about "decl mode" that most Flow users are completely unaware of (I never heard about it before reading through the PR discussion). I think it's unfortunate that a naming that exposes internals was chosen, I think one should aim to name things meant for external consumption based on the outside view, not based on what's (well hidden) inside.

Unfortunately I didn't make the call on this one. Flow was born largely out of the Hack team (and in fact still a lot of code is shared) so to me it's not surprising they wanted to align things this way. IMO [silence] is a little removed from from the functionality this provides because it doesn't silence all errors: parse errors will still be as loud as always. Discussion about this is perhaps best had in a separate issue though 👍

@mrkev well I think most people here want it to silence parse errors as well

That's what [ignore] is for.

And [untyped]. There  is nothing to silence with parse errors. $FlowFixMe does work in this case too.

@mrkev ignore ignores the whole thing. What I think people want is that internal issues are not reported. I cannot fix them. I still want to know about issues of how I use the API!

@mrkev ignore ignores the whole thing. What I think people want is that internal issues are not reported. I cannot fix them. I still want to know about issues of how I use the API! I DO care about he boundary layer. I do NOT care about what goes on behind it (I have no influence over it, not my package).

@jamesisaac it's not so much that tons of libraries have this problem, but rather that things like this which are stupidly cumbersome get more and more annoying over time.  There's no 100% ideal solution I can copy into each of my projects.
<PROJECT_ROOT>/node_modules/[a-z0-9\-]+/(lib|src|test)/.*\.json wouldn't catch files in node_modules/foo/node_modules/bar/test/bad.json, so the character range should at least include /.  Even this is not a foolproof solution, because should there be file with @flow that tries to require one of those ignored .json files will cause a Flow error.  Probably not the case in any of my dependencies, but I am agitating for a 100% foolproof way to suppress the malformed JSON errors once and for all.
AFAIK, Flow parses files under node_modules whether they're referenced or not.

The reality is that (it seems) a lot of us want type processing in node modules but NO errors shown in any node modules. We want errors to be shown in our own code when we missuse a module, but we don't want to see that any node modules did something wrong internally. We want to be able to maintain code that is error free and see that on a PR there are no flow errors, but we can't do that when node modules reports hundreds of errors for dependencies I can't control. Many of those errors for us are from Facebook modules, such as the react native fbsdk or react native itself. I still haven't found an easy way to accomplish this. Should be as easy as "If error originates from $glob, do not report or display"

authors: LegNeato Palisand STRML StribMaxMarti TrySound apsavin gabrielenosso haggholm icaroharry jedwards1211 jlaustill kylebebak lll000111 mrkev mruzekw nodkz ntomallen rcknight timLoewel vincenzovitale vith vladshcherbin yamov yleflour zeorin


text:
Fix the ocamlformat install step in the GitHub worflow

The code was previously using $INFER_ROOT which is not defined for this workflow.

Thanks for fixing this!

authors: jeremydubreil jvillard

repo: facebook/infer

license: mit

license_source: bigquery


text:
Add support for nice error messages with assert

Do you want to request a feature or report a bug?
Feature.
What is the current behavior?
Right now you only get nice assertions from Jest if you use expect.
What is the expected behavior?
It would be awesome to have nice error messages for assert built-in by default, like Ava does, because assert has a lot less downsides than expect.

I realize this is going to be potentially controversial, since many people use expect as their main assertion library, but please hear me out, because I think there are some pretty objectively good reasons to offer an alternative...
1. expect has long, hard to remember method names.
Things like toHaveBeenCalledWith or toBeGreaterThanOrEqual are easy to misspell and forget since they are so long to begin with. And typing them out gets pretty tedious.
2. expect has inconsistent naming schemes.
To solve the "hard to type" problem, expect adds some aliases. But the naming schemes are inconsistent with each other. For example, there is an alias for toHaveBeenCalled named toBeCalled. But the alias for toHasBeenLastCalledWith is not named toBeLastCalledWith, it's just lastCalledWith, which is unexpected.
3. expect uses incorrect grammar.
On top of it already being hard to remember long method names, many method names are not grammatically correct, making it even harder to remember them. For example, it is toBeLessThanOrEqual instead of toBeLessThanOrEqualTo. And it is toHaveBeenCalledTimes. But all of those built-in method names are awkward to say, and thus hard to remember.
4. expect is very unfriendly to non-English speakers.
If you consider the case of someone who isn't a native English speaker, trying to learn conjuctions and verb tenses correctly in English can be hard. But much of expect's API is tied to knowing specific conjuctions and verbs and tenses. For example it's toHaveLength, which is grammatically correct, but it's not easy to remember that it's not toBeLength, especially when "be" is heavily used elsewhere. Or for example it is toContain to check a child element, and not toHave.
This is made even worse by the previous issue, since some of the method names aren't grammatically correct to begin with, so it's even harder for non-English speakers.
5. expect doesn't build on Javascript's built-in functionality.
expect uses very specific method names to allow for nice error messages, which makes sense when you want to try to provide them at runtime. But with the rise of Babel and other source transformations this is no longer a requirement. And once you ditch that requirement, things like power-assert become available, which let you use the native Javascript syntax to express your tests.
Instead of something like:
expect(4).toBeGreaterThanOrEqualTo(0)
expect(value).not.toBeUndefined()
expect(string).toHaveLength(3)

You get to write:
assert(4 >= 0)
assert(value !== undefined)
assert(string.length == 4)

Which are readable by anyone who knows Javascript, without having to learn an API, without having to know English well, and without having to type long strings.
And they allow for more flexibility, because, "it's just Javascript". I think this is similar to how JSX gives you so much more flexibility over previous templating systems.

All of these issues add up to having to refer to the documentation much more often than should be necessary, and also having to write a lot more verbose assertions that should be necessary.
I open this not to start a fight, but because I think Jest's goal is pretty awesome, and I think including something like power-assert would make it even better.

I don't think this is controversial, there are two pieces to this:

Make assert better. I think @dmitriiabramov mentioned the error thrown from assert has some special stuff in it, so we can use that. The only problem is we are still using Jasmine, so it might be a bit annoying to make it work. Maybe Dmitrii has some suggestions.
A completely new, better assertion API. Right now we mimic Jasmine because it is pretty good. I agree with some of your points but in general expect is really, really good. However, I do want diversity in both assertion libraries and test runners. One of the coolest things I believe would be to ship Ava's test runner and assertion library by default in Jest. It would combine the strengths of both to make one super framework: Jest's scalability, snapshots, failure messages and awesome CLI/watch and Ava's far superior APIs. This is a much longer term thing and I'm excited about the potential here.

Finally, I am gonna put the hammer down a bit on "power-assert". I think it is way too crazy as a default. I don't wanna do anything to prevent you from using it though and you should already be able to, no? If no, then that should be fixed separately. We spent a ton of time making failures look really good and helpful this half and while we could bikeshed forever, the status quo is pretty and gives good signal.
None of the things I mention here are actively being worked on so whatever solution you think makes sense, taking it to a PR will make it more likely to get into Jest. Code wins arguments.

built-in assert generates an error that can be caught and prettyfied (mocha does this well)
This is actually something that we need to do at some point, just because some projects rely on native assert and unformatted errors look very confusing.
eslint rule tester is one of those projects. It work great with mocha, but with jest it throws errors with no information about what happened at all. (see https://github.com/eslint/eslint/issues/6532)
here's an example of an assert error.

however, when using assertion like this:

all you get is expected true to be false which is not really informative. And i don't think there's any way to get any meaningful information from there without static analysis (like power assert does).
I think the best option for now is to make expect as nice as possible and maybe simplify some methods + provide much nicer documentation

@cpojer @dmitriiabramov can we close this issue then?

i guess we're not going to get here anytime soon.
here's another issue for this https://github.com/facebook/jest/issues/1230
we should add a list of first bug tasks for other people who want to start contributing :)

Yes, same here, I really can't be bothered to learn or use all those expect(foo).to.have.some..
I made https://github.com/caub/deep-eq beause it's often useful to test deep objects, and I use it like the first comment, for every assertions. One API to learn

authors: caub cpojer dmitriiabramov ianstormtaylor thymikee

repo: facebook/jest


text:
Snapshots not generated when using setTimeout

I'm using setTimeout to wait 160ms before snapshotting my components, because it takes 150ms for them to animate into the visual state I want to test. The problem is, when I use setTimeout, Jest does not generate any snapshots, so the tests always pass. The expected behaviour is that Jest will generate snapshots.
import React from 'react';
import renderer from 'react-test-renderer';
import Tabs from '../src/components/tabs/Tabs';
import Tab from '../src/components/tabs/Tab';

test("Display a tab's content which its title is selected", () => {
  for (let i = 0; i < 3; ++i) {
    const component = renderer.create(
      <Tabs activeTabKey={`${i}`} onChangeActiveTabKey={() => {}}>
        <Tab tabKey='0' title='One'>One content</Tab>
        <Tab tabKey='1' title='Two'>Two content</Tab>
        <Tab tabKey='2' title='Three'>Three content</Tab>
      </Tabs>
    );

    setTimeout(() => {
      const tree = component.toJSON();
      expect(tree).toMatchSnapshot();
    }, 160);
  }
});

Tabs.js
import React from 'react';
import classNames from 'classnames';
import Tab from './Tab';

const {func, string} = React.PropTypes;

class Tabs extends React.Component {

  static propTypes = {
    activeTabKey: string,
    onChangeActiveTabKey: func.isRequired
  };

  static childContextTypes = {
    activeTabKey: string,
    visibleTabKey: string
  };

  getChildContext() {
    return {
      activeTabKey: this.state.activeTabKey,
      visibleTabKey: this.state.visibleTabKey
    };
  }

  state = {
    activeTabKey: this._getActiveTabKey(),
    visibleTabKey: this._getActiveTabKey()
  };

  _timer = null;

  _afterDelay = action => {
    if (this._timer) {
      clearTimeout(this._timer);
    }
    this._timer = setTimeout(() => {
      this._timer = null;
      action();
    }, 150);
  };

  _getActiveTabKey() {
    let activeTabKey = this.props.activeTabKey;
    if (activeTabKey == null) {
      const firstTab = this._tabs()[0];
      if (firstTab) {
        activeTabKey = firstTab.props.tabKey;
      }
    }
    return activeTabKey;
  }

  _tabs() {
    return React.Children.toArray(this.props.children).filter(child => child.type === Tab);
  }

  _onClickTab = tabKey => {
    if (this.props.activeTabKey != tabKey) {
      this.props.onChangeActiveTabKey(tabKey);
    }
  };

  _changeVisibleTab(nextActiveTabKey) {
    this.setState({visibleTabKey: null}, () => {
      this._afterDelay(() => {
        this.setState({
          activeTabKey: nextActiveTabKey,
          visibleTabKey: nextActiveTabKey
        });
      });
    });
  }

  componentDidUpdate({activeTabKey: prevActiveTabKey}) {
    if (this.props.activeTabKey != prevActiveTabKey) {
      this._changeVisibleTab(this.props.activeTabKey);
    }
  }

  componentWillUnmount() {
    if (this._timer) {
      clearTimeout(this._timer);
      this._timer = null;
    }
  }

  render() {
    return (

          {this._tabs().map((tab, index) => (

               {
                  e.preventDefault();
                  this._onClickTab(tab.props.tabKey)
                }}
              >
                {tab.props.title}

          ))}

          {this.props.children}

    );
  }
}

export default Tabs;

Tab.js:
import React from 'react';
import classNames from 'classnames';

const Tab = ({tabKey, title, className, style, children, ...props}, {activeTabKey, visibleTabKey}) => (

    {children}

);

const {any, string} = React.PropTypes;

Tab.propTypes = {
  tabKey: string.isRequired,
  title: any.isRequired
};

Tab.contextTypes = {
  activeTabKey: string,
  visibleTabKey: string
};

export default Tab;

Hi, there are several issues with your test.
First of all I would recommend to use Timer Mocks which should be more reliable than your solution. Next you use toMatchSnapshot() in a loop, snapshots are identified by the name of the test, this means that you will only have ONE snapshot, even though it seems you want to have three.
If you want to go with your solution and use setTimeout you should look at Testing Asynchronous Code, it explains how to use a callback to signal to jest that your test is done. Make sure to only call done() after all of your three calls to toMatchSnapshot are done.

Thanks for the tips. I was able to simply remove setTimeout because my assumption about the component needing time to settle was incorrect.
Having said that, it should be noted that the test is created inside the loop and therefore the snapshot file contains an array of three snapshotted renderings, whose names are made unique by appending a 1-based index. Nice!
Thanks for the pointer to mock timers. I'll look into it. Apologies for raising this issue erroneously.

authors: clentfort steve-taylor


text:
Unexpected test file matching due to parent directory name interfere with testRegex

Do you want to request a feature or report a bug?
bug
What is the current behavior?
Using config option testRegex that does not include test/... something, having tests in test/xxx.test.js will still be run.
The example in my case is: { "testRegex": "src/.*\.test\.js$" }
If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.
See https://github.com/mraxus/jest-always-test-test and use commands yarn test and yarn fail to see expected/unexpected behaviour
What is the expected behaviour?
yarn fail does not pass where it should.
Please provide your exact Jest configuration
module.exports = {
	testEnvironment: 'node',
    testRegex: 'test/unit/.*\\.test\\.js$',
};

vs
module.exports = {
	testEnvironment: 'node',
    testRegex: 'src/.*\\.test\\.js$',
};

Run npx envinfo --preset jest in your project directory and paste the
results here
  System:
    OS: macOS High Sierra 10.13.4
    CPU: x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
  Binaries:
    Node: 8.11.1
    Yarn: 1.5.1
    npm: 5.8.0
  npmPackages:
    jest:
      wanted: ^22.4.3
      installed: 22.4.3

@mraxus both of your tests in that repo pass for me:

So after some more troubleshooting with a colleague, I now understand what was going on.
So I have the absolute path as Users/me/src/js/project/. And as he pointed out, the testRegex uses the absolute path, not relative, which is not stated in the docs.
Personally I think the regex should only match the relative path as this is only what is relevant. Otherwise you get unexpected behaviour. Just like this case >p
But using the config: testMatch: ['<rootDir>/src/**/*.test.js'], then I can get the tests running as expected.
So my suggestion would be to either:

make testRegex path relative
clarify that these regex functions always work with absolute paths.

I will update the issue title / description

I feel like we got another issue (or PR) for the same thing not too long ago, but I'm unable to locate it...

Using <rootDir> is our standard way to opt into relative so I think that makes sense here
@mraxus would you be able to update the docs?

@rickhanlonii I will check it out and see what I can provide!

Docs updated, thanks @binygal

authors: SimenB mraxus rickhanlonii


text:
feat(jest-core, jest-watcher)!: move TestWatcher class to jest-watcher

Summary
As a TODO comment in jest-runner mentioned, it seems to be good idea to move TestWatcher class to jest-watcher. Noticed it while working on #12646 and just could not leave it.
Test plan
Green CI.

Ur deleting s*** like I am not watching for years

I just heard ur phone too 😜😂

authors: fuckurs mrazauskas


text:
fix link to genMockFromModule API documentation

Summary
Fix internal documentation link

Test plan

thank you!

authors: bakotaco cpojer


text:
Unexpected change in Kotlinlang formatting

ktfmt v0.51 with Kotlinlang formatting changed how the closing parenthesis of a multiline function call is placed.
Before:
foo(
    1,
    2
)

After:
foo(
    1,
    2)

There's no mention of this change in the changelog and it seems to go against Kotlinlang conventions. Was the change intentional or is this a bug?

It seems that the (still unreleased) commit cec9b501428d5236c306ce2b50adc4cbe0338ffe fixes this by turning on trailing comma management for kotlinlang.

repo: facebook/ktfmt


text:
Bug: Converting to markdown breaks the editor with certain contents

Playing around with markdown conversion, I noticed that sometimes, for certain content, the conversion fails and breaks the editor entirely.
Eg copying the contents of this page to the playground and trying to convert to markdown breaks the editor. Alternatively you can import this lexical state into the playground (I tried to attach a .lexical file but github doesn't let me):
{"editorState":{"root":{"children":[{"children":[],"direction":null,"format":"","indent":0,"type":"paragraph","version":1},{"children":[{"detail":0,"format":0,"mode":"normal","style":"","text":"You can unlock much more keyword data in ","type":"text","version":1},{"children":[{"detail":0,"format":0,"mode":"normal","style":"","text":"Keyword Gap","type":"text","version":1}],"direction":"ltr","format":"","indent":0,"type":"link","version":1,"rel":null,"target":null,"title":null,"url":"https://www.semrush.com/analytics/keywordgap/"}],"direction":"ltr","format":"","indent":0,"type":"paragraph","version":1},{"children":[{"children":[{"detail":0,"format":0,"mode":"normal","style":"","text":"l","type":"text","version":1}],"direction":"ltr","format":"","indent":0,"type":"link","version":1,"rel":null,"target":null,"title":null,"url":"https://www.semrush.com/analytics/keywordgap/"}],"direction":"ltr","format":"","indent":0,"type":"paragraph","version":1},{"children":[{"detail":0,"format":0,"mode":"normal","style":"","text":"Keyword Manager","type":"text","version":1}],"direction":"ltr","format":"","indent":0,"type":"paragraph","version":1},{"children":[{"children":[{"detail":0,"format":0,"mode":"normal","style":"","text":"Keyword Manager","type":"text","version":1}],"direction":"ltr","format":"","indent":0,"type":"link","version":1,"rel":null,"target":null,"title":null,"url":"https://www.semrush.com/analytics/keywordmanager/"}],"direction":"ltr","format":"","indent":0,"type":"paragraph","version":1}],"direction":"ltr","format":"","indent":0,"type":"root","version":1}},"lastSaved":1702327856275,"source":"Playground","version":"0.12.5"}

I think there might be multiple situations in which something like this occurs, since sometimes deleting random characters seems to fix it.
Locally it returns the error:
Uncaught Error: One or more transforms are endlessly triggering additional transforms. May have encountered infinite recursion caused by transforms that have their preconditions too lose and/or conflict with each other.

I tried figuring out which node or pattern was causing this, links, whitespace, whatever, but failed.
Lexical version: 0.12.5
Note: I'm not related to the blog page itself, it's just a sample in which this error occurs.
Steps To Reproduce

Paste the contents of  page into the lexical playground (or import a .lexical file with the trimmed version of the contents above)
Try to convert it to markdown
The editor will break

Hi! I guess it is similar to this one i just opened: #5403

repo: facebook/lexical


text:
Evaluate Profile-Guided Optimization (PGO) and LLVM BOLT

Feature Request
Is your feature request related to a problem? Please describe.
Not exactly a problem. Just an idea of how to improve the performance.
Describe the solution you'd like
According to my tests, PGO shows measurable improvements in compiler-like workloads (Clang-Tidy, Clangd, Clang, GCC, Rustc, etc.) I think it could be helpful to check PGO for the Mariana-Trench project too. E.g. here you can check the PGO results for Clang-Tidy.
We need to perform PGO benchmarks on Mariana-Trench. And if it shows improvements - add a note to the documentation about possible improvements in Mariana-Trench performance with PGO. Providing an easier way (e.g. a build option) to build scripts with PGO can be useful for the maintainers and end-users too.
Describe alternatives you've considered
Do nothing :)
Additional context
As an additional step after applying PGO, I can recommend trying to use LLVM BOLT.

Sure, PGO and LLVM BOLT are great. We could try LTO as well.
Some feedback for your issue and your repository:

It could helpful if you could give directly in your issue some concrete numbers for the potential win.
I personally found it a bit hard to navigate your repository with hundreds of links (some are broken for me, for instance the one for Firefox results). For instance, it took me a while to find instructions to build our project with PGO and Clang.

Regarding implementing PGO for this project: the setup seems non-trivial (not quite mature) and integrating it in our build system will be complicated (we have 2 of those, actually). Knowing that the performance win is not guaranteed, it seems like a risky project to take on.
NB: I can't help but notice that you opened a similar issue on more than 90 repositories. That feels a bit spammy.

It could helpful if you could give directly in your issue some concrete numbers for the potential win.

Sure. I cannot give you right now the potential win numbers for Mariana-Trench itself (since I didn't integrate the PGO in it yet). But as an estimation I can suggest you my results for Clang-Tidy. It's also a static analysis tool so Clang-Tidy's result should be relevant here. If one day I get the results for Mariana-Trench - definitely I will post them here.

I personally found it a bit hard to navigate your repository with hundreds of links

Thanks for the feedback! Right now I am trying to figure out, what is the better way to present all this information. So for now I can suggest navigating over Ctrl+F with the name of your project (like "Clang"). Also, I've tried to group the links of similar projects (similar == the same domain) into one place like "Compilers", "Operating systems", etc. Hope it helps.

some are broken for me, for instance the one for Firefox results

Could you please give me this link? I just rechecked all Firefox links - they work fine. I guess it could be a link to Google Groups, that does not allow unauthenticated access or something like that. But I will wait for a bit more information for debugging this issue.

For instance, it took me a while to find instructions to build our project with PGO and Clang.

Thanks! I will try to fix this.

Knowing that the performance win is not guaranteed, it seems like a risky project to take on.

Definitely is not guaranteed. But at least according to my tests, PGO shows improvements in all tested by me compiler-like workloads (static analysis, compilers, LSP implementations, even formatters). So you can estimate some performance wins based on the benchmarks for other projects.

NB: I can't help but notice that you opened a similar issue on more than 90 repositories. That feels a bit spammy. Not sure if there was a better way to do it.

Me too. Honestly, I do not think that it's "bad" spamming or something like that. I see many cases (like one, two, three) where people actually thanks for raising the optimization opportunity.
So I decided just speak with project maintainers via issues. Some are interested in PGO and we are discussing it further, some are not interested in performance (and it's completely ok - every project on every lifecycle stage has own priorities) and close the PGO-related issues. Also, via issues I collect feedback about my results (like you did with reporting for difficult navigation over the repo).

some are broken for me, for instance the one for Firefox results

Could you please give me this link? I just rechecked all Firefox links - they work fine. I guess it could be a link to Google Groups, that does not allow unauthenticated access or something like that. But I will wait for a bit more information for debugging this issue.

oh right, it's just because we have some kind of corporate google account which doesn't allow access to Google groups.
Link I was talking about: https://groups.google.com/g/mozilla.dev.platform/c/wwO48xXFx0A/m/ztg4i0DYAAAJ

Got it. I will extract the results directly to the repo for this case. Thanks!

repo: facebook/mariana-trench


text:
Selecting a non-unique option ignores the select box element

What are you trying to achieve? (Expected behavior)
Select an option from a specific select box (using selectOption).
E.g. if you have 2 <select> elements and both have an <option> with the same value.
<select id="s1"><option value="o1">o1</option></select>
<select id="s2"><option value="o1">o1</option></select>

It should let you select o1 within s2 with something like
$driver->selectOption('//*[@id="s2"]', 'o1');

What do you get instead? (Actual behavior)
It selects the first option that matches the value, not the option that matches that value AND is within the select box matching the supplied xpath.
As far as I can see the selectOptionOnElement function doesn't actually use the $element when finding the option.
Details

Php-webdriver version: 1.7.1
PHP version: 7.3.9
Selenium server version: ? ChromeDriver 77.0.3865.40
Operating system: macOS 10.14.6
Browser used + version: Chrome 77.0.3865.120

I don't actually see a selectOptionOnElement function anywhere, and selectOption is a protected function. From what I can tell, all of the functions.
I'm 99% sure that you are reporting a bug against the SilverStripe Mink Driver. I've already raised a pull request against that project (https://github.com/silverstripe/MinkFacebookWebDriver/pull/3) but it's sat untouched by the maintainer for 22 days.
As it happens I have created a new MinkFacebookWebDriver which is a fresh rewrite. I'm currently in the process of getting it ready for prime time and I'm hoping to do a proper release when we release version 1.8.0 of php-webdriver (or possibly v2.0). You can see my WIP work at https://github.com/andrewnicols/MinkFacebookWebDriver/. I apologise for the bizarre versioning. I made the mistake of releasing a 1.0.0 when I thought I'd finally got it all working and then discovered a heap of bugs which @OndraM and I have been working to fix and standardise.
Suggest closing this issue as there is no bug in this project.

@OndraM we can close this issue.

authors: andrewnicols matt-in-a-hat

repo: facebook/php-webdriver


text:
fix eclipse compiler TypeConversion error

This is a correctness fix; the Sun compiler compiles this statement but the Eclipse compiler requires the generic below.
However, this change must be applied after https://github.com/facebook/presto/pull/2994 because the checkstyle plugin 6.1.1 used in presto does not consider <T>:: a valid character sequence and flags it as an error.

Is the sun compiler broken? Or the eclipse compiler?

My, albeit limited, understanding is that the Sun compiler accepts the construct, while the Eclipse compiler is stricter and requires the code to have the explicit <T>.  I seem to remember a couple of those things in the past where the Sun compiler was more liberal than the Eclipse compiler.
The error message from ecg is "type mismatch, can not cast Iterator<Object> to Iterator<T>"

@jvanzyl do you know anything about this?

I'll take a look, but generally JDT (Eclipse compiler) is usually the spec compliant complier believe it or not. This may be not really be of much help but every time I've ever looked up an issue with Javac vs JDT, it's JDT which is correct and Javac that is not. Maybe a dozen times over the years.

rebase on top of trunk, now that #2994 has been merged, it should pass the CI build.

So, I found that IntelliJ warns that "Explicit type arguments can be inferred" and thus we need to suppress it:
@SuppressWarnings("RedundantTypeArguments")

In which case, it would be nice to link to a bug (Oracle or Eclipse) indicating why. I filed an IDEA issue here: https://youtrack.jetbrains.com/issue/IDEA-140958
@hgschmie can you file an issue with Eclipse?

I'll just merge this with a comment saying "Eclipse compiler requires this". Would be nice to run both compilers in the CI.

Merged, thanks!

authors: electrum hgschmie jvanzyl martint

repo: facebook/presto


text:
How can I get Image folder name in iOS? group_name is...

I'm retrieving group_name in Android CameraRoll.getPhotos to sort all the pictures into Album folders.
It was easy since on Android since data.edges.node.group_name is holding all the album names.
But I found out on iOS, all the image's group_name is 'All Photos'....
So I cannot sort with the same logic.
What can I do to sort Images into different folders name in 'My Albums'...?
Those customized folders by different apps..
Thanks in advance !

@facebook-github-bot stack-overflow

StackOverFlow isn't helping, I need a comment from an author...;;

authors: BROUDING DanielMSchmidt

repo: facebook/react-native


text:
rootTag changed when back button pressed

When I open my app for the first time, I get the following message on my logs:

Running application "AppName" with appParams: {"initialProps":{},"rootTag":1}. DEV === true, development-level warning are ON, performance optimizations are OFF

But whenever I quit my app with the Back button, I get the following message:

Running application "AppName" with appParams: {"initialProps":{},"rootTag":11}. DEV === true, development-level warning are ON, performance optimizations are OFF

The parameter rootTag is changed to 11. This prevents my to change scenes with my navigator through navigator.push({...}), as I receive the warning message:

Warning: Can only update a mounted or mounting component. This usually means you called setState, replaceState, or forceUpdate on an unmounted component. This is a no-op.
Please check the code for the exports component.

Any help?
Thanks in advance
Update
Every next time I exit the app with the Back button, the parameter rootTag is increased by 10, so becoming 21, 31, 41, ...

Hey, thanks for reporting this issue!
It looks like your description is missing some necessary information. Can you please add all the details specified in the template? This is necessary for people to be able to understand and reproduce the issue being reported.
I am going to close this, but feel free to open a new issue with the additional information provided. Thanks!

authors: hramos tomasdelima


text:
Textinput wrapped in another View causes maximum call stack

Description
TextInput usage  is wired.
Reproduction Steps and Sample Code
My View hierarchy:
A extends Component {
   render(this.props.innerView())
}

B extends Component {
   render(
      <A innnerView={this._renderInnerView}/>
   )
}

And my innerView contains a TextInput .
In Android , My TextInput is below :
<TextInput
                style={{flex: 1}}
                autoCapitalize='none'
                placeholder={strings.addLinkTitleHint}
                keyboardType='default'
                enablesReturnKeyAutomatically={true}
                autoCorrect={false}
                onChangeText={(text) => {
                    console.log("text : ", text);
                    if (this.state.modifyingTitle === text) {
                        return;
                    }
                    this.setState({
                        modifyingTitle: text
                    })
                }}
                underlineColorAndroid='rgba(0,0,0,0)'
                value={this.state.modifyingTitle}
            />

I just could get one time log info, and after seconds, I get "Maximum call stack size exceeded" error.
I found the render method in A is called many times, but i do not know how to solve it.
Additional Information

React Native version: [0.44]
Platform: [iOS, Android]

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with Canny! Check out its new home: https://react-native.canny.io/feature-requests/p/textinput-wrapped-in-another-view-causes-maximum-call-stack

@zhuyifan2013 do you still face the issue? If not, how did you solve it?

authors: hramos royalcheeseburger zhuyifan2013


text:
Image onLoad called twice on rerender

Environment
Environment:
OS: macOS High Sierra 10.13.5
Node: 9.4.0
Yarn: 1.3.2
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 9.3 Build version 9E145
Android Studio: 3.0 AI-171.4443003
Packages: (wanted => installed)
react: ^16.4.0 => 16.4.1
react-native: ~0.54.4 => 0.54.4
Description
Any time that a file re renders, the source={{uri '...'}} of the  refetches the image from the url even though the image had been already fetched..
I know this because visually the image flickers due to the refetch... and the onLoad / onProgress is recalled multiple times..
How can I limit the amount of fetch calls for an Image component to only once if already fetched?

Try use React.PureComponent


text:
0.62.1 Error: Unable to resolve module ./YellowBoxImageSource

Please provide all the information requested. Issues that do not follow this format are likely to stall.
Description
pristine react-native init, attempted to react-native run-android, during run time got yellowbox error.  Did not occur with 0.62.0.
React Native version:
Run react-native info in your terminal and copy the results here.
info Fetching system and libraries information...
System:
OS: Windows 10 10.0.18363
CPU: (8) x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
Memory: 18.09 GB / 31.95 GB
Binaries:
Node: 12.9.1 - C:\Program Files\nodejs\node.EXE
Yarn: Not Found
npm: 6.14.4 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK:
API Levels: 22, 23, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.3, 26.0.1, 26.0.3, 27.0.3, 28.0.3, 29.0.0, 29.0.2
System Images: android-23 | Intel x86 Atom_64, android-23 | Google APIs Intel x86 Atom, android-23 | Google APIs Intel x86 Atom_64, android-24 | Google Play Intel x86 Atom, android-26 | Google APIs Intel x86 Atom_64, android-26 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom
Android NDK: Not Found
IDEs:
Android Studio: Version  3.5.0.0 AI-191.8026.42.35.6010548
Languages:
Python: 2.7.13 - C:\Python27\python.EXE
npmPackages:
@react-native-community/cli: Not Found
react: 16.11.0 => 16.11.0
react-native: 0.62.1 => 0.62.1
npmGlobalPackages:
react-native: Not Found
Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.

npx react-native init xxx
npx react-native run-android

Expected Results
See the sample react native screen

I can confirm, here's the stack for more detail:
error: Error: Unable to resolve module `./YellowBoxImageSource` from `node_modules/react-native/Libraries/YellowBox/UI/YellowBoxInspectorHeader.js`:

None of these files exist:
  * node_modules/react-native/Libraries/YellowBox/UI/YellowBoxImageSource(.native|.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
  * node_modules/react-native/Libraries/YellowBox/UI/YellowBoxImageSource/index(.native|.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
    at ModuleResolver.resolveDependency (/Users/manu/Code/mtd-mobile/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:163:15)
    at ResolutionRequest.resolveDependency (/Users/manu/Code/mtd-mobile/node_modules/metro/src/node-haste/DependencyGraph/ResolutionRequest.js:52:18)
    at DependencyGraph.resolveDependency (/Users/manu/Code/mtd-mobile/node_modules/metro/src/node-haste/DependencyGraph.js:287:16)
    at Object.resolve (/Users/manu/Code/mtd-mobile/node_modules/metro/src/lib/transformHelpers.js:267:42)
    at /Users/manu/Code/mtd-mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:434:31
    at Array.map (<anonymous>)
    at resolveDependencies (/Users/manu/Code/mtd-mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:431:18)
    at /Users/manu/Code/mtd-mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:275:33
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/Users/manu/Code/mtd-mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:87:24)

I also experience the same since yesterday.. Nothing has changed in any file, but same code worked well day before yesterday.
[Sat Apr 04 2020 12:15:00.350]  BUNDLE  ./index.js
error: Error: Unable to resolve module ./YellowBoxImageSource from node_modules\react-native\Libraries\YellowBox\UI\YellowBoxInspectorHeader.js:
None of these files exist:

node_modules\react-native\Libraries\YellowBox\UI\YellowBoxImageSource(.native|.android.js|.native.js|.js|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
node_modules\react-native\Libraries\YellowBox\UI\YellowBoxImageSource\index(.native|.android.js|.native.js|.js|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
at ModuleResolver.resolveDependency (F:\projects\React-Native\chat-app\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:163:15)
at ResolutionRequest.resolveDependency (F:\projects\React-Native\chat-app\node_modules\metro\src\node-haste\DependencyGraph\ResolutionRequest.js:52:18)
at DependencyGraph.resolveDependency (F:\projects\React-Native\chat-app\node_modules\metro\src\node-haste\DependencyGraph.js:287:16)
at Object.resolve (F:\projects\React-Native\chat-app\node_modules\metro\src\lib\transformHelpers.js:267:42)
at F:\projects\React-Native\chat-app\node_modules\metro\src\DeltaBundler\traverseDependencies.js:434:31
at Array.map ()
at resolveDependencies (F:\projects\React-Native\chat-app\node_modules\metro\src\DeltaBundler\traverseDependencies.js:431:18)
at F:\projects\React-Native\chat-app\node_modules\metro\src\DeltaBundler\traverseDependencies.js:275:33
at Generator.next ()
at asyncGeneratorStep (F:\projects\React-Native\chat-app\node_modules\metro\src\DeltaBundler\traverseDependencies.js:87:24)

yes for me also same error

same error. Caan't develop further.
solve as soon as possible.

I tried react-native start --reset-cache.
Afterwards I once again ran npx react-native run-android and it worked.
See this  on stackoverflow.

Same issue with 0.62.1, this worked for me:
watchman watch-del-all
rm -rf $TMPDIR/haste-map-metro*
rm -rf $TMPDIR/metro-cache*
rm -rf node_modules
npm cache clean --force
npm install
npm start -- --reset-cache

I tried react-native start --reset-cache.
Afterwards I once again ran npx react-native run-android and it worked.
See this  on stackoverflow.

That worked!  Thanks!

npx react-native start --reset-cache fixed the above issue for me too.

I tried react-native start --reset-cache.
Afterwards I once again ran npx react-native run-android and it worked.
See this  on stackoverflow.

Superb. Issue Solved. Thank you so much. Close the Issue.

I'm glad you were able to find a resolution for this!

npx react-native start --reset-cache
and i got
Command start unrecognized. Make sure that you have run npm install and that you are inside a react-native project.

Eu tentei react-native start --reset-cache.
Depois corri mais uma vez npx react-native run-androide funcionou.
Veja isso no stackoverflow.

That also worked for me!! Thanks!!

this worked 0.63.2
watchman watch-del-all
rm -rf $TMPDIR/haste-map-metro*
rm -rf $TMPDIR/metro-cache*
rm -rf node_modules
npm cache clean --force
npm install
npm start -- --reset-cache


text:
Android. The size of SO binary libraries are doubled by bumping min SDK to 23

Description
By bumping a version of minSDK from 21 to 23. The size of the APK is doubled. Inspector says that all binaries became heavier. Is there any idea why it could happen?
React Native version:
"react-native": "0.63.2"
hermes is ON
Steps To Reproduce
assembleRelease command with min SDK 21 and 23 generates APKs with unexpectable results of file size.
49.6Mb and 88.9MB
Expected Results
The size should be quite the same.
Snack, code example, screenshot, or link to a repository:

Thanks.

This is the expected behavior. The explanation of why this is happening can be found here https://stackoverflow.com/a/63417612

authors: Gark cortinico


text:
TypeError: Cannot read properties of undefined (reading 'getItem') with RN 0.71.1

New Version
0.71.1
Old Version
0.67.1
Build Target(s)
iOS Simulator
Output of react-native info
react-native info
info Fetching system and libraries information...
(node:22495) Warning: Accessing non-existent property 'padLevels' of module exports inside circular dependency
(Use node --trace-warnings ... to show where the warning was created)
System:
OS: macOS 13.1
CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Memory: 1.64 GB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.14.2 - ~/Library/Caches/fnm_multishells/16855_1674563217976/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 8.5.0 - ~/Library/Caches/fnm_multishells/16855_1674563217976/bin/npm
Watchman: 2022.03.21.00 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
Android SDK:
API Levels: 28, 29, 31, 32
Build Tools: 28.0.3, 29.0.2, 30.0.2, 31.0.0, 32.0.0, 32.1.0
System Images: android-30 | Google Play Intel x86 Atom, android-31 | Google APIs Intel x86 Atom_64, android-31 | Google Play Intel x86 Atom_64
Android NDK: Not Found
IDEs:
Android Studio: 2021.1 AI-211.7628.21.2111.8309675
Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
Languages:
Java: 11.0.11 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.2.0 => 18.2.0
react-native: 0.71.1 => 0.71.1
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Issue and Reproduction Steps
in package.json
"ts-jest": "^28.0.5",
"babel-jest": "^29.2.1",
 "@types/jest": "^29.2.1",
"@types/react-test-renderer": "^18.0.0",

yarn test -u
FAIL  screens/tests/UniversalLogin.test.js (12.085 s)
Login Page With Universal Auth0 Login
✕ Matches snapshots (1920 ms)
● Login Page With Universal Auth0 Login › Matches snapshots
TypeError: Cannot read properties of undefined (reading 'getItem')

  42 |
  43 |   test('Matches snapshots', () => {
> 44 |     const snapshot = render(instance).toJSON();
     |                            ^
  45 |     expect(snapshot).toMatchSnapshot();
  46 |   });
  47 | });

The same problem:

Same thing with Amplify.Auth, did anyone find a solution?

authors: LayMui parnekov professorkolik