Jest 25's change in behaviour of collectCoverageFrom option

💥 Regression Report
After upgrading from Jest 24 to Jest 25 we are seeing more files in our coverage reports that we used to have. It seems like the behaviour of the collectCoverageFrom glob patterns has changed.
Last working version
Worked up to version: 24.9.0
Stopped working in version: 25.1.0
To Reproduce
Our folder structure is the following:

client/

extension/

chrome/

js/

__tests__/

some_file.js

module.js

Our jest.config.js has the following option:
collectCoverageFrom: [
    '!**/__mocks__/**',
    '!**/__tests__/**',
    'extension/**'
  ],

Expected behavior
The expectation is that coverage is collected from module.js but NOT from some_file.js. In Jest 24 this is the case, but in Jest 25 coverage is being collected from some_file.js even though we've set '!**/__tests__/**',.
To work around this, we had to explicitly add '!extension/chrome/js/__tests__/**' to the list of directories and that made Jest 25 ignore it.
Link to repl or repo (highly encouraged)
Hopefully the details above are enough. If not, I can help setup a test repo to reproduce.
Run npx envinfo --preset jest
Paste the results here:
  System:
    OS: macOS 10.15.2
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
  Binaries:
    Node: 10.17.0 - ~/.nvm/versions/node/v10.17.0/bin/node
    Yarn: 1.21.1 - /usr/local/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v10.17.0/bin/npm
  npmPackages:
    jest: 25.1.0

I can confirm that  joelpalmer solution works fine. I went through the same change of behavior but that did it.

Upgrading to Jest 25.2.4 has resolved this issue for us! We didn't have to make any changes to our collectCoverage config.

For me, the original issue is still occurring in 25.2.4. Even though I specified:
'!**/__tests__/**',

to be ignored, I'm still seeing directories from extension/chrome/js/__tests__/ inside my coverage report.

I don't think we've changed anything to address this. I don't really think we can work around it either, without downgrading micromatch which we really don't wanna do (it'd be a breaking change as well)

Sorry for the radio silence on this. I’ll try to get this resolved in micromatch ASAP.
Sent from my iPhone

On Mar 31, 2020, at 5:44 PM, Simen Bekkhus<EMAIL_ADDRESS>wrote:
I don't think we've changed anything to address this. I don't really think we can work around it either, without downgrading micromatch which we really don't wanna do (it'd be a breaking change as well)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

@jonschlinkert are there any news on this issue on the micromatch side?

@csvan This should have been fixed in micromatch 4.0.4, can someone confirm if issues goes away after the upgrade?

https://github.com/micromatch/micromatch/issues/179
<EMAIL_ADDRESS>was released today. According to changes, they bumped picomatch to fix negated globs issue, however it didn't work for me.
With such settings
    "collectCoverageFrom": [
      "src/**/*.{js,jsx,ts,tsx}",
      "!src/theme/**",
      "!src/**/*.generated.{ts,tsx}",
      "!src/gql/__generated__/**"
    ],

I still see src/theme/index.ts, src/gql/__generated__/generated.introspection-result.ts and some .generated.ts files in a coverage report. This workaround https://github.com/facebook/jest/issues/9464#issuecomment-580245682 didn't help as well.
coveragePathIgnorePatterns works as expected.
Could anyone please check if new micromatch will work for them?

For people seeing improvements from rolling back micromatch, please see #11293

To sum it up.

The issue @joelpalmer reported was fixed in #11287 (not released yet). Basically negated patterns of the form !(<anything>)<something>
I haven't yet looked at the issue that @atsikov posted.
The changed behaviour for the example ['!**/__mocks__/**', '!**/__tests__/**', 'extension/**'] is now documented in #11341. The breaking change in jest 25 was that the order of globs now matters and has an effect.
In the given example:

collectCoverageFrom: [
    '!**/__mocks__/**',
    '!**/__tests__/**',
    'extension/**'
  ],

What this basically means is

Ignore everything in __mocks__ and __test__ but include all files in extension

Because the order matters the last glob is simply overwriting the two negations, so in the end the config simply means

Include everything in extension

To fix the behaviour ensure that the order of globs does make sense for your case. In the example it would mean moving the negated patterns to the end of the array:
collectCoverageFrom: [
    'extension/**',
    '!**/__mocks__/**',
    '!**/__tests__/**',
  ],

Thanks for clarifying here @danez! As you say, this change of behaviour is correct (albeit somewhat unexpected as it is not mentioned in Micromatch's changelog).
So I think we can close this 🙂


Users without delete permissions on manage allocations do not see warning message

Steps to reproduce.
Create a scratch org with test data.
Create a user with access to general allocations and allocations (read/write only).
Login as the user.
Go to an opportunity with GAU's and click on the Manage Allocations button.
Attempt to delete an Allocation row.
Warning message should be displayed.

**lurch: attach W-030472

Tracking W-030472

Included in beta release 3.149 (Beta 9)

Included in production release 3.149


[Request] Add grid reference

All major browsers will soon support CSS grids. So it might be a good idea to add CSS grid reference.
PS: 👍 Thanks for this reference. Flexbox visual reference was both comprehensive and concise.

Yeah I need to have a go at CSS grids first. But I'll definitely add it.

I'd love to see a grid reference section being added as well. Please also let me know if there's anything I can do to help out

Bump, thank you for this awesome site! Do you need any assistance with the grid layout?


Bugfix/TS 247 Update Assessor Info

What's included?
Issue: User Raised Issue BR_000058 #247

Fix Firebase syntax in the store assessment.js.
Check the assessment question before accessing it.

Note: The PR required the changes in digital-platform: Bugfix/TS 247 Update Assessor Info #1054.
Who should test?
✅ Product owner
✅ Developers
How to test?
Example exercise: https://jac-admin-develop--pr2355-bugfix-ts-247-update-qejdbf0q.web.app/exercise/ONqUjAzhDS7rjh6dFJLB/tasks/all/independent-assessments
Example application: https://jac-admin-develop--pr2355-bugfix-ts-247-update-qejdbf0q.web.app/exercise/ONqUjAzhDS7rjh6dFJLB/applications/applied/application/X5ToXRooJbu9h6AVRtuA

Go to the application and update the information (type, full name, email) of the first/second assessor.
Go to "Independent Assessments" and check if the information of the assessor has been updated.

Risk - how likely is this to impact other areas?
🟢 No risk - this is a self-contained piece of work
Additional context
Include screen grabs, video demo, notes etc.
Related permissions
Have permissions been considered for this functionality?

No permission changes required
Permissions have been added / updated. Details:

PREVIEW:DEVELOP
can be OFF, DEVELOP or STAGING

On the application I was able to update the information (type, full name, email) of the first/second assessor.
and on Independent Assessments" the information of the assessor has been updated. No issues ..


Add big example app

In the coming month I will be developing a big cyclejs app as example how to build and structure a larger cycle app. The development will be accompanied by a blog series and an egghead.io video course. To set the scope of the app, I will outline the basic requirements. If you have anything to add, feel free to leave a comment.
The app will be a chat app, similar to gitter. It will feature:

definitely

Live messaging
Multiple rooms
Keeping track of read/unread messages
Login/Auth
Mark all read (@geovanisouza92)
Presence indicator (@geovanisouza92)
Timestamps (@raquelxmoss)

most likely

" is typing..." (@geovanisouza92)
Notifications (@geovanisouza92)
@mentions (@geovanisouza92)
pinned messages (@geovanisouza92)
@cycle/time tests

maybe

offline usage (PWA)
form validation (editable user profile)
Server side rendering + hydration
Save specific messages as bookmarks (@geovanisouza92)

most likely not

Embedding link previews (@geovanisouza92)

This means under the hood it will use:

definitely

@cycle/dom
@cycle/http
@cycle/time
cycle-onionify
cyclic-router
a custom websocket driver
cyclic-router (@brucou)

maybe

custom validator wrapper (will be published as seperate package)

I'm interested to hear additional requirements :)

Nice to have:

Mark all read
Presence indicator
" is typing..."
Notifications?
@mentions?
Embedding link previews? (Let me dream high :rofl:)
Save specific messages as bookmarks (as well pinned messages on a room)

If you implement Save specific messages as bookmarks you will probably also use some form of routing. That could go in your definitely section.

Not sure if you had already planned for this, but displaying timestamps on messages might be good -- that would probably introduce Cycle Time. It would also be good to see tests.

 Although the chatting cats app is a little different from what I had in mind there (issue tracker), many of the features might still be useful to have examples of.

Is this designed to be a learning tool or a usable app?
If the former, then I don't think we need every possible feature - just enough to demonstrait all usefull patterns in code.

This is a great initiative, we've been talking about it for a while, so it's good to see it becoming concrete. :)
Jan, I noticed you had some difficulty labeling this issue ("discussion", "scope examples", "large"), and I'm also scratching my head about it. What will be the outcome? Will it be one example in those among the /examples directory, or its own repository? Given how fast it will be updated, I would imagine it's better as its own repository, but could still live in the cyclejs github org. What do you think?

I'm not completely sure either ^^
For development I would put it in a different repo, because it's easier to develop from scratch. Afterwards we can still put it in the examples/ directory

small technical concern, i'd like to see how you guys resolve message passing with onionify lenses. Basically parents/children 'talking' to each other. I have my way, but I'd love to see yours :)

I think one more thing to go along with presence indicator could be async loading of user data and displaying it in multiple places. See chatting cats.
When a new "user" joins the chat, their avatar is displayed as a grey circle with three dots ("loading").
Once the user data has been loaded, the avatar is updated with user avatar, and it is immediately displayed in several places: in the chat list on the left (if it was the last user to type a message), in the current message list (if the user had any messages there).
Other than that,

I would put the large app in its own repo and keep it there. Use common
tools on it like Travis CI and GreenKeeper. GreenKeeper does not support
monorepos.
On Tue, Oct 10, 2017, 10:15 dmitriid<EMAIL_ADDRESS>wrote:

I think one more thing to go along with presence indicator could be async
loading of user data and displaying it in multiple places. See chatting
cats http://tonsky.me/datascript-chat/.
When a new "user" joins the chat, their avatar is displayed as a grey
circle with three dots ("loading").
Once the user data has been loaded, the avatar is updated with user
avatar, and it is immediately displayed in several places: in the chat list
on the left (if it was the last user to type a message), in the current
message list (if the user had any messages there).
Other than that,
https://camo.githubusercontent.com/b200ba4082266050777eb64a660092414b11e41f/68747470733a2f2f692e70696e696d672e636f6d2f353634782f31312f39322f35632f31313932356363316363316466316664303330336535623936313066333730302d2d6a616b652d7468652d646f67732d616476656e747572652d74696d652d66696e6e2e6a7067
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cyclejs/cyclejs/issues/705#issuecomment-335382767,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmyx1GqTxmrDzNFZmgOS5aGPtgu2aJuks5sqxmegaJpZM4PtoIP
.

Closing this in favor of #851


How to access the state of Alamofire.Request

How do I check the state of the actual request that was made? I need to know whether the request is still in progress without hooking into the completion handler.
Alamofire.Request exposes a state property for this. But Moya wraps this Request into a Cancellable protocol that just exposes isCancelled nothing else related to the state.
Moya Version 14.0.0
Not using RxMoya or ReactiveMoya
Alamofire Version 5.0.2

Hey @tarun-personatech - I think it's not currently possible due to wrapping in our cancellable type. There are plans to extend this to support more than just the cancelling part though (like resuming, and possibly other functionalities). For now I guess you would have to work around this by setting the state yourself if possible (depending on your architecture, if you have an abstraction layer on top of MoyaProvider, you could store array of cancellables and update it once the request starts/stops so you know if it is in progress or not)

Thanks @sunshinejr , I kind of knew the answer and realized it won't be possible without adding to Cancellable type or at the least without exposing the alamofire request in CancellableToken.
I will find some workaround. Thanks again.

One question though. I am not at all familier with RxSwift but planning to start using it. Would this thing be possible if I use RxMoya which I guess returns a Signal?

@tarun-personatech hmm I don't think so, no, since Single does only provide an abstraction over the Response you will normally get from Moya. Meaning, you will get a form of "stream of Responses" instead of just Response (Observable<Response>) or just a specialized stream of values, that is in fact only one value (success/failure, Single<Response>). It still uses a Cancellable under the hood for the request logic.


Fix returned torch tensors

Description
Fix returned torch tensors
Related Issue
None
Type of change

[ ] This change requires a documentation update
[x] This change affects the client
[ ] This change affects the server
[ ] This change affects the API
[ ] This change only concerns the documentation

How Has This Been Tested?
@mbrunel tested it
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have updated the documentation according to my changes

that's a weird pre-commit hook fail,, ???

Can you please explain more in details what is this commit for, and show me an example of what it solve?


jps: Watch geeksforgeeks.org

jps requests the watch of the watch_keyword geeksforgeeks\.org. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

geeksforgeeks\.org has been seen in 12 true positives, 194 false positives, and 102 NAAs.

Discussions spam https://chat.stackexchange.com/transcript/message/65361088#65361088

Approved by tripleee in Charcoal HQ

My bad, should not have approved this.


[NuGet BaGet]: Added new BaGet service (Self hosted NuGet server)

This PR adds support for version & download badges from a BaGet server.
I'm not sure how to add examples / tests for this new service due to it's self hosted nature and no public instance being available (that I'm aware of)
I've tested badge generation against our local (private) BaGet instance with the following commands:
npm run badge -- /baget/v/<PackageName?source=<Instance url>
npm run badge -- /baget/vpre/<PackageName>?source=<Instance url>
npm run badge -- /baget/dt/<PackageName?source=<Instance url>

I've extended the logic from nuget-v3-service-family to support the small differences in API in the BaGet server api implementation, mainly searching without the packageid parameter and the package version being available in the response, without need for lookup in the versions array (which is also sorted in DESC, not ASC)

Sorry it has taken quite a while to respond to this.
Given you say that there is no public instance of BaGet, this seems like a badge that would only be relevant to users who self host a shields instance. Would that be a reasonable assessment?
In general, we don't add these.
Related reading:
https://github.com/badges/shields/blob/b1f5aecf36c716cd642c27b4569d04abef335dee/doc/releases.md?plain=1#L31-L36
and
https://github.com/badges/shields/pull/9666#issuecomment-1838736622
I did start an issue about a possible way to deal with this at https://github.com/badges/shields/issues/9787 but I'm not sure it will go anywhere. I don't think any of us are convinced on the tradeoffs.
All of that said, quite a common thing we do is support compatibility with a private or self-hosted version of a centralised service as long as your private instance is API compatible with the centralised version. So our GitLab badges will work with your self-hosted GitLab as long as it is running a version that is API-compatible with https://gitlab.com/ Our Packagist badges will work with your private packagist install as long as it is running a version that is API-compatible with https://packagist.org/ and so on. Essentially, if we can test against a public instance and also tack on a ?registry_url= param (or whatever), that works for us.
So here's my question: There are some BaGet-specific customisations going on in this PR, but would it be possible to deliver a subset of what you're trying to do here by bolting an optional parm onto NuGet and documenting that it also works with BaGet, or is BaGet not quite API compatible enough for that to work? i.e: are the changes in this PR BaGet-related enhancements or are they fundamentally necessary to get the thing to work?

I understand the concerns about maintaining an integration with a provider that can't easily be tested.
Reading the issues that you linked, is this something that should be implemented using the endpoint or dynamic/json badges then?

The dynamic json badge has the advantage that you can make custom badges just by constructing a URL. So using a URL that returns JSON like https://pypi.org/pypi/pip-abandoned/json I can construct a URL like https://img.shields.io/badge/dynamic/json?query=info.requires_python&label=python&url=https%3A%2F%2Fpypi.org%2Fpypi%2Fpip-abandoned%2Fjson that extracts a value from it and puts it on a badge.
The downside of this is that it can only take you so far. If you want to do something more advanced than just extract a value and display it, for example:

change the colour of the badge conditionally based on the value
perform some kind of calculation like adding several numbers together
additional formatting (e.g: rounding a number, or displaying a number of bytes as Kb/Mb/Gb)

you can't do that with the dynamic badge.
With the endpoint badge, the sky's the limit. You can have all that and a bag of chips, but you do need to host the endpoint that can call your API, do whatever processing you need, and serve a JSON document conforming to the badge schema somewhere, and we recognise this does represent some additional overhead.

I'm personally aligned on above points as well. I don't think we'll want to move forward with this badge for the time being, so will go ahead and close the PR. Let's keep an eye on #9787 as the next step.
Anyhow, thanks for your interest in the Shields.io project, @lluiscab!


[Bug]: Force layer to refetch data

Mapbox Implementation
Mapbox GL
Mapbox Version
default
Platform
iOS, Android
@rnmapbox/maps version
10.0.0-beta.11
Standalone component to reproduce
I am currently able to show a set of "zones" in my map. However, at a certain point, the app gets notified and we need to refetch all layers (e.g. because the color of a zone changed).
How do I force the refetching of a layer (the one below)?
I tried passing in a ref and doing ref.current.forceUpdate() but that doesn't work.
After receiving the update to refetch data, if I zoom in and out - at certain zoom levels the right color shows but if I zoom in too much it disappears. Is this a bug? Is this a cache issue?
Any help is greatly appreciated.
          <MapboxGL.VectorSource
            id="zone_layer"
            minZoomLevel={MinZoomLevel}
            tileUrlTemplates={buildTileTemplatesURLs('zone')}>
            <MapboxGL.FillLayer
              ref={zoneRef}
              id="evacuation_zone"
              style={{
                fillColor: ['get', 'color'],
                fillOpacity: 0.4,
                fillOutlineColor: '#232323',
              }}
              sourceID="zone_layer"
              sourceLayerID="zone"
            />
....

Observed behavior and steps to reproduce
No response
Expected behavior
I expect the layer to refetch and redraw all the tiles.
Notes / preliminary analysis
No response
Additional links and references
No response

There is no forceUpdate you might be able to use react-native key to force readd of source/layer

@mfazekas changing the key did not work. The layer stays the same. On the web, it's working properly.


WebBluetooth API

The package is marked as compatible with flutter web at
https://pub.dev/packages/flutter_ble_lib
I do not see any code in the repository to support that.
This would be a very fine addition to the library if it would also work on the upcoming flutter web.

Hi!
It's marked as compatible because we haven't switched to new pubspec.yaml format, I'll try to fix it next week.
I haven't researched WebBluetooth API, but my colleague mentioned once it might be too different from the mobile one. I'll leave the ticket open to check for compatibility some time, but there are no plans to support it as of now.

I tested the WebBluetooth API locally with some samples and the workflow is a little different because before connecting a dialog pops up to authorize a specific device. Probably a good thing for privacy ...
The API seems on paper easy enough to be integrated.
We would help to test and perhaps will even be willing to implement as soon as we enter into production with a specific mobile app.

If we are about to have the same API for Android, iOS and WebBluetooth then the lowest common demnominator would be WebBluetooth API — it requires a specific type of handling. As far as I know one cannot create a generic sniffer app using WebBluetooth API because to be able to interact with some services these need to be defined before establishing a connection. That's for starters.
Anyway we have that on our stack to research and think of how to address API differences.


Suggestion: Make getBlobName return empty string if GoogleStorageResource is a bucket

This is a suggestion PR for when getBlobName() is called, GoogleStorageResource should return empty string instead of null.
Followup to discussion in #1478 - Elena suggested possibility of returning empty string instead of null.
On further inspection, I think getBlobName() should return an empty string instead of null when the resource is a bucket. This is because the empty string is more useful as a value; the main argument for this is usage of expression that pops up:
blobPath = (blobPath == null) ? "" : pathToFile

Within storage module this is done twice and this was also done in my work with vision OCR. I begin to fell that it is inconvenient to have to check for null and then convert to empty string.

Codecov Report

Merging #1500 into master will decrease coverage by <.01%.
The diff coverage is 85.71%.

@@             Coverage Diff             @@
##             master   #1500      +/-   ##
===========================================
- Coverage     69.61%   69.6%   -0.01%
+ Complexity     1611    1608       -3
===========================================
  Files           222     222
  Lines          6158    6156       -2
  Branches        639     638       -1
===========================================
- Hits           4287    4285       -2
  Misses         1599    1599
  Partials        272     272

Flag
Coverage Δ
Complexity Δ

#integration
?
?

#unittests
69.6% <85.71%> (-0.01%)
1608 <5> (-3)

Impacted Files
Coverage Δ
Complexity Δ

...ework/cloud/gcp/storage/GoogleStorageLocation.java
85% <85.71%> (-0.72%)
17 <5> (-3)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2aac7b3...b527e94. Read the comment docs.

@dzou I think I raised my concern before that something not existing should generally be null not empty string. I don't remember what came of that discussion though. Note that if you want to test whether the resource is a bucket (i.e. no blob), there is the isBucket method.

Would it be fair to say that while "blob" does not exist, "blobName" is empty?

@dzou I think I raised my concern before that something not existing should generally be null not empty string. I don't remember what came of that discussion though. Note that if you want to test whether the resource is a bucket (i.e. no blob), there is the isBucket method.

Understood, in this case it feels different because the empty string is a much more useful value. I made this suggestion PR because in my code, I am repeating this line a lot:
blobPath = (blobPath == null) ? "" : pathToFile
i.e. I check whether blobPath is null or not, and if it is, I will set it to empty string. This comes up a lot when using the Storage API (here) or in general when you are formatting a URI string "gs://" + bucketName + "/" + blobPath. In such cases one must convert blobPath to a empty string to use it.
If it is the case that representing a bucket's blobPath with "" or null are roughly equal on principle, then I think the empty string wins out because it has the usability advantage.

Note that a GCS resource can either be a bucket or a blob. Once you know which one it is, you don't need code like blobPath = (blobPath == null) ? "" : pathToFile.
Futhemore, if you just need the path to the GCS resource, we already have the GoogleStorageResource.getURI() method. Have you tried using it?


CFP: BGP Route Learning

Cilium Feature Proposal
NOTE:  This GitHub issue is accompanied by a formal CFP under https://github.com/cilium/design-cfps/pull/58
Cilium's Border Gateway Protocol implementation is one-directional today.  It's intended use is for the advertisement of pod and service IP addresses/prefixes to the network.  The network however is unable to influence Cilium's routing decisions using BGP or by any other means.  Cilium at present expects a simple network design at the node level where all routing needs can be satisifed using a default route.  The upstream router is assumed capable of making all routing decisions and to have connectivity to all necessary routing domains.
In advanced network designs, the administrator may desire to establish connectivity between Cilium and several isolated routing domains.  For example, one routing domain may provide connectivity to all other Kubernetes nodes, another routing domain may provide connectivity only to the Internet, while a third may provide connectivity only to storage resources.  On the network upstream of Cilium, these domains may be isolated using various techniques such as Virtual Routing and Forwarding (VRF) instances, and even physical isolation with dedicated physical network interface cards (NICs).
When configured for Native-Routing mode, it appears possible to support the advanced network design described above.  However, doing so in large environments would require complex management and automation for Linux routing tables.
Related links:

Previous feature request:  https://github.com/cilium/cilium/issues/23464

Closing as the corresponding RFP was withdrawn.


Need to set color background

If a light color scheme is applied, it makes sense to set background=light, which also allows for executing an auto-command based on the value of 'background'. So does for a dark color scheme.

And only set background if the the current background doesn't match the color scheme to be applied.

I will add this.

done