profile
viewpoint
Simen Bekkhus SimenB @folio-as Oslo, Norway

facebook/jest 29789

Delightful JavaScript Testing.

siimon/prom-client 1180

Prometheus client for node.js

istanbuljs/istanbuljs 512

monorepo containing the various nuts and bolts that facilitate istanbul.js test instrumentation

af/envalid 452

Environment variable validation for Node.js

istanbuljs/babel-plugin-istanbul 446

A babel plugin that adds istanbul instrumentation to ES6 code

SimenB/add-asset-html-webpack-plugin 275

Add a JavaScript or CSS asset to the HTML generated by html-webpack-plugin

istanbuljs/v8-to-istanbul 48

convert from v8 coverage format to istanbul's format

danielhusar/gulp-stylint 29

Gulp plugin for stylus stylint linter

SimenB/babel-preset-es3 8

Preset for Babel's ES3 transformations

push eventSimenB/jest

Simen Bekkhus

commit sha 1f7857f6d4ef33a3aeeca4feef3a616fd529bf8e

chore: bump realpath-native

view details

Mark Pedrotti

commit sha 7817dcc9a6e2fca9a6dddc634339b0006199ee43

website: Update pictures of reports when matchers fail (#9214) * website: Update pictures of reports when matchers fail * Update CHANGELOG.md * Move line in CHANGELOG.md * Replace name of obsolete image file in index.js

view details

Grex

commit sha 8607684d4cea110edc5605e50d2e3af6194404a2

chore: downgrade jest-snapshot#semver to v6 to support node 8 (#9451)

view details

Matt Riedemann

commit sha eee81208163d2b64171a6b7eec13a8a1aebfc901

Document testTimeout configuration option (#9449)

view details

Simen Bekkhus

commit sha 895136f3f4be9155f1b60b55e77b8c285feb6a73

chore: remove unused deps from @jest/reporters (#9462)

view details

mbpreble

commit sha 03a78775b70b1a7b0d4bc672492460a8a9d6af6a

Produce source maps when instrumenting code (#9460)

view details

StringEpsilon

commit sha 084508290f4a90b28c3190021d3358ab1f753c3f

docs: Warn about node-notifier caveat on windows systems. (#9454) fixes #9452

view details

mkoliba

commit sha 0a958e8e6280ac6d9c36a2d410414fa73f3b2e6f

docs: clarify error handling when using test callbacks (#9365)

view details

Ron Korving

commit sha 4d32070c1273a7d6566721c8d81648ad6e68856d

Remove bash syntax highlighting from GitHub issue template (#9474)

view details

Simen Bekkhus

commit sha 10d3cef30b4fc7261909aa3d8f0298c3266fcd01

chore: cleanup package.jsons

view details

Simen Bekkhus

commit sha bc195e4f178dbd581e1788cfa7256101158f4961

chore: more cleanups

view details

Ron Korving

commit sha 28f6da44cc58d41438bddfa9fcd741fd01b02ded

Remove bash syntax highlighting from GitHub issue template (#9482)

view details

Simen Bekkhus

commit sha cd6f7553ad4a7910cfc5e0932ee3d83f04e548e5

chore: replace mkdirp with make-dir (#9486)

view details

Simen Bekkhus

commit sha 5196b71115a9b05e2cac4bae84ce925dcf307e3c

fix: export `OldPlugin` from pretty-format (#9491)

view details

doniyor2109

commit sha 523ba3bfdb278be82590f50f5ef951b37fdc4802

feat: override `module.createRequire` (#9469)

view details

Sam Rae

commit sha b9a7787fd20b10b841ff035dc86a201b0ee7c079

Add link to mock function documentation (#9391) * Add link to mock function documentation SpyOn section does not include a link to the mock function description. Added a link to that. * update versioned_docs Co-authored-by: Tim Seckinger <seckinger.tim@gmail.com>

view details

Simen Bekkhus

commit sha ffdaa751f5356de5bbdd0a906c30f31558fa2f3a

chore: update changelog for `module.createRequire`

view details

Orkhan Alikhanov

commit sha c9127bfec38882f02abed4bf41514f1843708ecb

Support array of paths for `moduleNameMapper` aliases (#9465)

view details

Scott Taylor

commit sha fdd700f85652502e8a881498197dded049a02372

fix: normalize setupFilesAfterEnv from user and presets (#9495)

view details

Wei An Yen

commit sha 0fba8e38451dac02fbcd810595b6845d1a156439

Fix diff highlight of symbol-keyed object. (#9499) * Fix diff highlight of symbol-keyed object * add symbol-keyed object tests * update changelog

view details

push time in 4 hours

startedexcalidraw/excalidraw

started time in 5 hours

startedChecksum/critic.sh

started time in 5 hours

issue commentfacebook/jest

Wrong coverage when using arrow function with return

Report it to Istanbul

nelsyeung

comment created time in a day

issue commentfacebook/jest

test.concurrent and snapshot support.

async tests should work fine... are you forgetting an await somewhere? If not, please open up a new issue with a reproduction as it's not really related to .concurrent - it should work fine

cpojer

comment created time in a day

issue closedsiimon/prom-client

gauge.startTimer(labels) misses timestamp parameter

It's not possible to set timestamps if you use gauges startTimer function.

closed time in a day

Sebi2020

issue closedsiimon/prom-client

Only custom collectors should be able to expose timestamps

https://github.com/siimon/prom-client#timestamps indicates that direct instrumentation can specify timestamps, and other code indicates that a /metrics will always have timestamps.

This makes no sense semantically, and breaks ingestion, timestamps, and staleness on the Prometheus end. All ability to set timestamps with direct instrumentation should be removed, and there should be no timestamps on /metrics in normal circumstances.

closed time in a day

brian-brazil

issue closedsiimon/prom-client

Not all the default collectors respect the `timestamps: false` configuration

The workaround for #177 is

To disable metric timestamps set timestamps to false (You can find the list of metrics that support this feature in test/defaultMetricsTest.js):

  • https://github.com/siimon/prom-client#default-metrics

But not all metrics support this, these did not:

# HELP process_cpu_user_seconds_total Total user CPU time spent in seconds.
# TYPE process_cpu_user_seconds_total counter
process_cpu_user_seconds_total 4.900423 1578088304120
# HELP process_cpu_system_seconds_total Total system CPU time spent in seconds.
# TYPE process_cpu_system_seconds_total counter
process_cpu_system_seconds_total 0.440623 1578088304120
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 5.3410459999999995 1578088304120
# HELP process_resident_memory_bytes Resident memory size in bytes.
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 97550336 1578088306184
# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 789307392 1578088306184
# HELP process_heap_bytes Process heap size in bytes.
# TYPE process_heap_bytes gauge
process_heap_bytes 146132992 1578088306184
# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 310 1578088304595
# HELP nodejs_eventloop_lag_seconds Lag of event loop in seconds.
# TYPE nodejs_eventloop_lag_seconds gauge
nodejs_eventloop_lag_seconds 0.490566822 1578088304611
# HELP nodejs_active_requests_total Total number of active requests.
# TYPE nodejs_active_requests_total gauge
nodejs_active_requests_total 131 1578088304121
# HELP nodejs_heap_space_size_total_bytes Process heap space size total from node.js in bytes.
# TYPE nodejs_heap_space_size_total_bytes gauge
nodejs_heap_space_size_total_bytes{space="read_only"} 262144 1578088304121
nodejs_heap_space_size_total_bytes{space="new"} 33554432 1578088304121
nodejs_heap_space_size_total_bytes{space="old"} 18722816 1578088304121
nodejs_heap_space_size_total_bytes{space="code"} 1474560 1578088304121
nodejs_heap_space_size_total_bytes{space="map"} 790528 1578088304121
nodejs_heap_space_size_total_bytes{space="large_object"} 2813952 1578088304121
nodejs_heap_space_size_total_bytes{space="code_large_object"} 49152 1578088304121
nodejs_heap_space_size_total_bytes{space="new_large_object"} 0 1578088304121
# HELP nodejs_heap_space_size_used_bytes Process heap space size used from node.js in bytes.
# TYPE nodejs_heap_space_size_used_bytes gauge
nodejs_heap_space_size_used_bytes{space="read_only"} 32296 1578088304121
nodejs_heap_space_size_used_bytes{space="new"} 1779952 1578088304121
nodejs_heap_space_size_used_bytes{space="old"} 13502648 1578088304121
nodejs_heap_space_size_used_bytes{space="code"} 1078048 1578088304121
nodejs_heap_space_size_used_bytes{space="map"} 584960 1578088304121
nodejs_heap_space_size_used_bytes{space="large_object"} 2794456 1578088304121
nodejs_heap_space_size_used_bytes{space="code_large_object"} 3552 1578088304121
nodejs_heap_space_size_used_bytes{space="new_large_object"} 0 1578088304121
# HELP nodejs_heap_space_size_available_bytes Process heap space size available from node.js in bytes.
# TYPE nodejs_heap_space_size_available_bytes gauge
nodejs_heap_space_size_available_bytes{space="read_only"} 229576 1578088304121
nodejs_heap_space_size_available_bytes{space="new"} 14979856 1578088304121
nodejs_heap_space_size_available_bytes{space="old"} 5191736 1578088304121
nodejs_heap_space_size_available_bytes{space="code"} 322784 1578088304121
nodejs_heap_space_size_available_bytes{space="map"} 204160 1578088304121
nodejs_heap_space_size_available_bytes{space="large_object"} 0 1578088304121
nodejs_heap_space_size_available_bytes{space="code_large_object"} 0 1578088304121
nodejs_heap_space_size_available_bytes{space="new_large_object"} 16759808 1578088304121

I think this is a known bug, its mentioned in the tests, but I couldn't find an issue for it. Sorry if its a duplicate.

  • https://github.com/siimon/prom-client/blob/cc9ce780ce59207c48fec79c539de947801348ee/test/defaultMetricsTest.js#L74-L79

closed time in a day

sam-github

pull request commentfacebook/jest

Upgrade JSDOM 16

The circus run complains about a memory leak. Is it correct or flake?

lamhieu-vk

comment created time in 2 days

pull request commentfacebook/jest

WIP: Upgrade JSDOM 16

We'll want getVmContext as well https://github.com/SimenB/jest-environment-jsdom-sixteen/blob/fd898842676e8f888feddbf4c4af81a3517e0306/index.js#L104

lamhieu-vk

comment created time in 2 days

delete branch SimenB/jest

delete branch : ts-3.8

delete time in 2 days

push eventfacebook/jest

Simen Bekkhus

commit sha c3c155f8832647b59a225a8f3136732dca71f6e4

chore: bump to typescript@3.8 (#9607)

view details

push time in 2 days

PR merged facebook/jest

chore: bump to typescript@3.8 cla signed

<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->

<!-- Please remember to update CHANGELOG.md in the root of the project if you have not done so. -->

Summary

https://devblogs.microsoft.com/typescript/announcing-typescript-3-8/

We won't be able to use much of the new syntax (https://github.com/typescript-eslint/typescript-eslint/pull/1465) but the stricter checks etc are 👍

<!-- Explain the motivation for making this change. What existing problem does the pull request solve? -->

Test plan

Green CI

<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->

+6 -5

2 comments

3 changed files

SimenB

pr closed time in 2 days

push eventSimenB/jest

Simen Bekkhus

commit sha c419c6d637398f7a55f1cbbc259f53b43f0f435b

moar ignore in istanbul stuff

view details

push time in 2 days

pull request commentsiimon/prom-client

fix: TypeScript declaration - strict label values

https://www.npmjs.com/package/tsd is pretty nice for writing type tests.

But yeah, defaulting to string should work fine, I think?

kobiburnley

comment created time in 2 days

PR opened facebook/jest

chore: bump to typescript@3.8

<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->

<!-- Please remember to update CHANGELOG.md in the root of the project if you have not done so. -->

Summary

https://devblogs.microsoft.com/typescript/announcing-typescript-3-8/

We won't be able to use much of the new syntax (https://github.com/typescript-eslint/typescript-eslint/pull/1465) but the stricter checks etc are 👍

<!-- Explain the motivation for making this change. What existing problem does the pull request solve? -->

Test plan

Green CI

<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->

+5 -5

0 comment

2 changed files

pr created time in 2 days

create barnchSimenB/jest

branch : ts-3.8

created branch time in 2 days

issue commentfacebook/jest

Async testing fails with async/await

Yeah, that'd be wonderful. Go for it!

yanickrochon

comment created time in 3 days

pull request commentnodejs/docker-node

Update node.js v13.x to v13.9.0 with Yarn v1.22.0

Ah, cool. Thanks for the link 👍

PeterDaveHello

comment created time in 3 days

issue commentfacebook/jest

Infinite loop clicking a select inside a label

Might be something weird RTL is doing, but it's at least closer 🙂

foxbunny

comment created time in 3 days

pull request commentnodejs/docker-node

Update node.js v13.x to v13.9.0 with Yarn v1.22.0

@rvagg any idea why the alpine build is not available? Is it https://github.com/nodejs/node/issues/31858?

PeterDaveHello

comment created time in 3 days

issue commentfacebook/jest

Infinite loop clicking a select inside a label

sorry, jest-environment-jsdom-sixteen

foxbunny

comment created time in 3 days

issue commentfacebook/jest

Infinite loop clicking a select inside a label

You can install jest-environment-jsdom@16 if you wanna verify against the latest JSDOM release.

foxbunny

comment created time in 3 days

issue closedfacebook/jest

Infinite loop clicking a select inside a label

<!-- Love Jest? Please consider supporting our collective: 👉 https://opencollective.com/jest/donate -->

🐛 Bug Report

I've discovered that if a select list is nested inside a label element, jest goes into an infinite loop if a click is triggered on the select.

It appears that this is triggered by a click propagating from select to label, which in turns tries to send a click event back to the select because when a label is clicked, normally an associated element receives the click as well.

I was not sure whether to report this here or to jsdom project, since the jsdom code I tracked this down to lives inside jest (or at least that's what I think). Apologies if this is the wrong place.

To Reproduce

Steps to reproduce the behavior:

  1. Create some code that will render a <select> inside a <label>
  2. Write a test that triggers the click event on the select
  3. Observe the Maximum call stack error

Expected behavior

I expected the click to work normally.

Link to repl or repo (highly encouraged)

https://codesandbox.io/s/eloquent-pike-7uw1h

envinfo

  System:
    OS: macOS 10.15.3
    CPU: (8) x64 Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
  Binaries:
    Node: 13.7.0 - /usr/local/bin/node
    Yarn: 1.21.1 - /usr/local/bin/yarn
    npm: 6.13.6 - /usr/local/bin/npm
  npmPackages:
    jest: ^25.1.0 => 25.1.0 

closed time in 3 days

foxbunny

issue commentfacebook/jest

Infinite loop clicking a select inside a label

Yeah, this is an issue either in RTL or JSDOM 👍

foxbunny

comment created time in 3 days

push eventSimenB/jest

Anders Kaseorg

commit sha 3d09c5c0c0f336af2e30f5e2e0252913a5cb36dd

Allow instrumentation of transformed files with non-js file extensions (#9589)

view details

Simen Bekkhus

commit sha 56565cc04c7261c5a3222a0547bea58c024ec0b8

chore: move execution of `setupFiles` to `jest-runner` (#9596)

view details

Dmitri

commit sha c2a879dc9dccb104731e71ab9908b74b8dcb1fa2

Fix --testNamePattern matching against it.concurrent within describe (#9090)

view details

Simen Bekkhus

commit sha b5c24e9efd03a841018b957f90b426d801c90a3d

feat: pass ESM options to tarnsformers

view details

Simen Bekkhus

commit sha a75f365a3253445b06c59074c84426936493c292

link to PR

view details

Simen Bekkhus

commit sha b1ab46226ad6abe1196444374666b3bec27f86d3

in instrument file as well

view details

Simen Bekkhus

commit sha 9657e91ac06cc23c00a88b19d2135b78e4fbe39e

oops

view details

Simen Bekkhus

commit sha 348f375407399db5f60437dad7398d6eb2166eba

update snaps

view details

Simen Bekkhus

commit sha a7fac13f93b4e5d8bbc145a8fd68f15b85ecc186

each

view details

push time in 3 days

issue commentexpo/expo

[expo-local-authentication] Refactor is/has/supported-functions

Somewhat related - https://developer.android.com/preview/features#biometric-auth

LinusU

comment created time in 3 days

push eventSimenB/jest

Dmitri

commit sha c2a879dc9dccb104731e71ab9908b74b8dcb1fa2

Fix --testNamePattern matching against it.concurrent within describe (#9090)

view details

push time in 3 days

push eventfacebook/jest

Dmitri

commit sha c2a879dc9dccb104731e71ab9908b74b8dcb1fa2

Fix --testNamePattern matching against it.concurrent within describe (#9090)

view details

push time in 3 days

PR merged facebook/jest

Fix --testNamePattern matching against it.concurrent within describe cla signed

<!-- Please remember to update CHANGELOG.md in the root of the project if you have not done so. -->

Summary

This PR aims to fix an issue with it.concurrent where a test is marked as PASSED without even being invoked when --testNamePattern is used to select the test. This has been reported e.g. in #5071. The issue also manifests every time a single test (defined with it.concurrent) is run in the WebStorm IDE using the "run" gutter icon.

Fixes #5071

Test plan

I included an integration test that demonstrates the issue.

+43 -12

3 comments

5 changed files

dmitri-gb

pr closed time in 3 days

issue closedfacebook/jest

test.concurrent does not run with testNamePattern when inside describe block

<!-- THIS IS NOT A HELP FORUM. If you are experiencing problems with setting up Jest, please make sure to visit our Help page: https://facebook.github.io/jest/help.html -->

<!-- Before creating an issue please check the following:

  • you are using the latest version of Jest
  • try re-installing your node_modules folder
  • run Jest once with --no-cache to see if that fixes the problem you are experiencing. -->

Do you want to request a feature or report a bug?

bug

What is the current behavior?

A test within a describe block can be executed using --testNamPattern but making the test concurrent causes the test to be marked as passed and not actually execute at all.

https://repl.it/repls/RoyalblueWornHomalocephale

What is the expected behavior?

A test can be executed correctly regardless of whether it is marked as concurrent or not and regardless of whether it is inside a describe block or not.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system. Jest 21.2.1 node 6.12.0 npm 3.10.10 Windows 10

closed time in 3 days

mfulton26

pull request commentnodejs/docker-node

Update node.js v13.x to v13.9.0 with Yarn v1.22.0

generate-stackbrew-library.sh doesn't handle that, see https://github.com/docker-library/official-images/pull/7429#discussion_r376126962

PeterDaveHello

comment created time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha c1e8f0eeba68837007277c8f2df7642269ffcf68

maybe?

view details

push time in 3 days

issue commenthipstersmoothie/jest-github-reporter

Create Github Action

@stefanbuck sorry, missed your last message. I still think a dedicated reporter makes more sense than a problem matcher. However, we could probably output some json on a single line per test failure or something - would that be parseable?

atifsyedali

comment created time in 3 days

issue commentfacebook/jest

Add CI reporters (AppVeyor, CircleCI, etc) and automatically enable when appropriate

Related: https://github.com/hipstersmoothie/jest-github-reporter/issues/67

Daniel15

comment created time in 3 days

issue commentfacebook/jest

Error stacks are broken in Jest watch mode for source mapped files

@ArtemGovorov you've solved this upstream?

ArtemGovorov

comment created time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha d0a72c03519b7d4b8383286fd77bcd291e8ee15d

maybe remove another internal from ci

view details

push time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha a4c0e7a5d97f68af2e5a409c5b08e7ae7dbc2e98

update snap

view details

Simen Bekkhus

commit sha 464fffe1e447693188d0bb953c62307f838bc667

remove one more internal thing

view details

Simen Bekkhus

commit sha a0500cae0355ea3ba9ba89cff82a7fa65446cc21

no promisify

view details

push time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha abd183ca31c18352bce51b356b4735824408d7de

no promisify

view details

Simen Bekkhus

commit sha 3b705eec500eb27a285a6cb2bbb275bad4e8e594

update snap

view details

Simen Bekkhus

commit sha 6e27752b7a771ccc3473a88d0a99c4ce597f5437

remove one more internal thing

view details

push time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 type ProcessResultOptions = Pick<   Config.GlobalConfig,   'json' | 'outputFile' | 'testResultsProcessor' > & {-  collectHandles?: () => Array<Error>;+  collectHandles?: (keepOpen: boolean) => Array<Error>;   onComplete?: (result: AggregatedResult) => void;   outputStream: NodeJS.WriteStream; }; -const processResults = (+const wait = promisify(setTimeout);

ah, CI complains. Doesn't locally though...

SimenB

comment created time in 3 days

pull request commentfacebook/jest

fix: improve open handles detection

Hmm, weird CI sees a bunch if stuff I don't see locally...

SimenB

comment created time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 type ProcessResultOptions = Pick<   Config.GlobalConfig,   'json' | 'outputFile' | 'testResultsProcessor' > & {-  collectHandles?: () => Array<Error>;+  collectHandles?: (keepOpen: boolean) => Array<Error>;   onComplete?: (result: AggregatedResult) => void;   outputStream: NodeJS.WriteStream; }; -const processResults = (+const wait = promisify(setTimeout);

affect how? this just creates a new function in the module scope

SimenB

comment created time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha 319ae72a4dbd8a6a2e4ac0d824d6cce6e5fbd795

keep message-util change

view details

push time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha 1aee52fdc86064014365488b7708d8d7c0382fa0

linefeed tweaks

view details

push time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 // Jest Snapshot v1, https://goo.gl/fbAQLP +exports[`deals with http servers and promises 1`] = `+Jest has detected the following 1 open handle potentially preventing Jest from exiting:+Of them 1 was collected within 100ms of the tests completing.

I pushed that, since it's an improvement regardless

SimenB

comment created time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha ca628c90c38d3beddf73efd33caa2f9b4d071dfb

ditch headings

view details

push time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 // Jest Snapshot v1, https://goo.gl/fbAQLP +exports[`deals with http servers and promises 1`] = `+Jest has detected the following 1 open handle potentially preventing Jest from exiting:+Of them 1 was collected within 100ms of the tests completing.

image

thoughts? I kept the heading, since if there were many collected, it looked really noisy...

SimenB

comment created time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 // Jest Snapshot v1, https://goo.gl/fbAQLP +exports[`deals with http servers and promises 1`] = `+Jest has detected the following 1 open handle potentially preventing Jest from exiting:+Of them 1 was collected within 100ms of the tests completing.

I like it!

SimenB

comment created time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha 3b0178680f5759f96bda0a47edf38bb5777fe1a6

update snap after copyright

view details

Simen Bekkhus

commit sha 900f518a423f669c924425973bdd94ced2abc9dc

rollback unneeded message-util changes

view details

push time in 3 days

pull request commentDefinitelyTyped/DefinitelyTyped

[@babel/core]: add `supportsDynamicImport`

I think all parts of caller that the core preset/plugins care about should be added to the type here

SimenB

comment created time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha 73674e07d87e88a821aa79c408a2fff881b5013d

copyright header

view details

push time in 3 days

pull request commentfacebook/jest

fix: improve open handles detection

My work project now looks like this, btw (the zlibs were there before as well):

image

So we keep the serverwrap from supertest that was previously removed, but we mark it as "collected". I think that makes sense 🙂 Hopefully people will look at the uncollected ones with stack trace first.

SimenB

comment created time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 export async function runCLI(     );   } -  const {openHandles} = results;+  if (globalConfig.detectOpenHandles) {+    const formatted = formatHandleErrors(results.openHandles, configs[0]); -  if (openHandles && openHandles.length) {-    const formatted = formatHandleErrors(openHandles, configs[0]);+    if (formatted.length > 0) {+      const uncollectedHandles = formatted+        .filter(({wasCollected}) => !wasCollected)+        .map(({stack}) => stack);+      const collectedHandles = formatted+        .filter(({wasCollected}) => wasCollected)+        .map(({stack}) => stack); -    const openHandlesString = pluralize('open handle', formatted.length, 's');+      const openHandlesString = pluralize('open handle', formatted.length, 's'); -    const message =-      chalk.red(-        `\nJest has detected the following ${openHandlesString} potentially keeping Jest from exiting:\n\n`,-      ) + formatted.join('\n\n');+      const alreadyCollectedString =+        collectedHandles.length === 0+          ? ''+          : collectedHandles.length === 1+          ? '1 was'+          : `${collectedHandles.length} were`; -    console.error(message);+      let heading = chalk.red(+        `Jest has detected the following ${openHandlesString} potentially preventing Jest from exiting:`,+      );++      if (alreadyCollectedString) {+        heading += chalk.yellow(+          `\nOf them ${alreadyCollectedString} collected within 100ms of the tests completing.\nThese are sometimes useful to look at as they might have spawned other handles that remain open, but that we have lost the origin of.`,+        );+      }++      const uncollectedHandlesString =+        uncollectedHandles.length > 0+          ? `Uncollected handles:\n${uncollectedHandles+              .map(line => line.trimRight())+              .join('\n\n')}`+          : 'There were no uncollected handles - this is unexpected if your tests do not exit cleanly.';++      const collectedHandlesString =+        collectedHandles.length > 0+          ? `\n\nCollected handles:\n${collectedHandles+              .map(line => line.trimRight())+              .join('\n\n')}`+          : '';++      const message = `\n\n${heading}\n${uncollectedHandlesString}${collectedHandlesString}`;++      console.error(message);+    } else {+      console.error(chalk.red('\nJest was unable to detect any open handles'));

previously it said nothing - we now print a small message to tell the user that "yes, the flag you passed did something"

SimenB

comment created time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 // Jest Snapshot v1, https://goo.gl/fbAQLP +exports[`deals with http servers and promises 1`] = `+Jest has detected the following 1 open handle potentially preventing Jest from exiting:+Of them 1 was collected within 100ms of the tests completing.

this probably isn't clear enough...

SimenB

comment created time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 This usually means that there are asynchronous operations that weren't stopped i `;  exports[`prints out info about open handlers 1`] = `-Jest has detected the following 1 open handle potentially keeping Jest from exiting:+Jest has detected the following open 3 handles potentially preventing Jest from exiting:+Of them 1 was collected within 100ms of the tests completing.+These are sometimes useful to look at as they might have spawned other handles that remain open, but that we have lost the origin of.+Uncollected handles: +  ●  DNSCHANNEL+ ++  ●  TCPSERVERWRAP++

just pushed it 🙂

SimenB

comment created time in 3 days

Pull request review commentfacebook/jest

fix: improve open handles detection

 This usually means that there are asynchronous operations that weren't stopped i `;  exports[`prints out info about open handlers 1`] = `-Jest has detected the following 1 open handle potentially keeping Jest from exiting:+Jest has detected the following open 3 handles potentially preventing Jest from exiting:+Of them 1 was collected within 100ms of the tests completing.+These are sometimes useful to look at as they might have spawned other handles that remain open, but that we have lost the origin of.+Uncollected handles: +  ●  DNSCHANNEL+ ++  ●  TCPSERVERWRAP++

you were too quick though, so I force pushed. sorry about duplicate diffs 😬

SimenB

comment created time in 3 days

push eventSimenB/jest

Simen Bekkhus

commit sha 01c19f51d31a7ad90e08035edf3ee683e9495852

show both collected and uncollected handles

view details

push time in 3 days

push eventSimenB/jest

Anders Kaseorg

commit sha 3aef4482c074a7655aa0ba79b03f32f246c585fc

docs/Configuration: Correct signature for testRunner (#9553)

view details

Simen Bekkhus

commit sha 7d5956101c7755d4201337bbee2070628ace59fd

fix: use file urls when calling `import()` (#9558)

view details

Simen Bekkhus

commit sha 47b8aaec0a6bb80b96f7641d68c76587d86abe23

chore: run GH Actions on windows as well (#9540)

view details

Simen Bekkhus

commit sha b3bfc338f1bb715942dbb2bebc77b43984a84a43

chore: bump to `react-native@0.61` in examples (#8884)

view details

Simen Bekkhus

commit sha 14e3992b82c8a05bf5856ecf88399f4ce62b3924

fix: do not default coverageProvider in yargs (#9562)

view details

Hieu Lam

commit sha 2793c67e36e245a2832fa2c39123e1ec507023a2

fix: `moduleNameMapper` should take precedence over Node core modules (#9563)

view details

Simen Bekkhus

commit sha 00e9e0972bf959e041b1dd249d907402a58c23b5

fix: notifications should be fire&forget rather than having a timeout (#9567)

view details

Luan Nguyen

commit sha 9bacc376ff8e0c431e46f9c21eab37a39e65b868

Ensure pattern of `replacePosixSep` is a string (#9546)

view details

Simen Bekkhus

commit sha 5f817428cae42c88aac1d751239d1d937501ef93

fix: verify `rootDir` and all `roots` are directories (#9569)

view details

태완

commit sha 4a559b7b760af896bb42a26586f6b2b57b475a3c

chore: replace `findDOMNode()` in examples/typescript (#9300)

view details

jfgreffier

commit sha f9cb36abbded0c3227cf3e212d5af888e738e87e

chore: add babel classProperties plugin to snapshot example (#9343)

view details

Tobias Hernstig

commit sha ccd00160a9cd38103d2f9f7d0cadfb9f5fbf1507

docs: add note for verbose option defaults (#9279)

view details

Andrew Stegmaier

commit sha f47ade4edb112261e14be459185e2396d9c8cbfc

Update documentation to clarify --watch behavior (#9276)

view details

Florent Vilmart

commit sha 9d1236b483b5a4687706e2fc0cb0732b84a2aa06

adds ability to pass custom reporter options (#9572)

view details

Lucas Azzola

commit sha 83aad6978ac1217fac3bcb77c42196a3a68a7879

Handle ERR_REQUIRE_ESM when reading configuration (#9573)

view details

doniyor2109

commit sha d4a10f7d41c4ccb4f6a02ee7fd25da972c3f0c34

fix: `toEqual` throws error when comparing readonly properties (#9575)

view details

Anton Alexandrenok

commit sha 63593a2d9a51eba11505fc6b9bc9de887b263f6c

fix(cli): .cjs & .mjs files support by "--config" option (#9578)

view details

Christoph Nakazawa

commit sha e2ad3a5fec4d379575fe5044cce344f8f4dae0ce

[jest-haste-map] Remove `mapper` option. (#9581)

view details

Michał Pierzchała

commit sha 1ed46e71a058c93b529e5e3f9388a800352de21a

fix: vscode eslint on save settings (#9584)

view details

Leonardo Villela

commit sha 2b83f7571d10e71f38e6b2134925a90abf52a8af

fix: crash on unix based systems without `find` (#9579)

view details

push time in 3 days

issue commentfacebook/jest

changedSince runs specs related to files with no diff

This is because we use git log rather than git diff, see https://github.com/facebook/jest/blob/56565cc04c7261c5a3222a0547bea58c024ec0b8/packages/jest-changed-files/src/git.ts#L53-L74

I do agree this is not expected, though. @alsuren do you remember why you went with log rather than diff?

/cc @thymikee @jeysal do you agree it's not expected behavior?

finn-orsini

comment created time in 3 days

issue closedfacebook/jest

ArrayBuffer Equals

describe("describe1", () => {
  it("test1", () => {
    const buf1 = new ArrayBuffer(334);
    const buf2 = new ArrayBuffer(334);
    new DataView(buf2).setInt32(0, 111);

    expect(buf1).not.toEqual(buf2);
  });
});

closed time in 3 days

kgtkr

issue commentfacebook/jest

ArrayBuffer Equals

This issue does not have enough details to be actionable. Please open up a new issue following the reproduction steps

kgtkr

comment created time in 3 days

Pull request review commentDefinitelyTyped/DefinitelyTyped

[node-notifier]: add `timeout: false` option

-// Type definitions for node-notifier 5.4.0+// Type definitions for node-notifier 5.4.1

Could you fix it? I'm away from the computer for a few days

SimenB

comment created time in 4 days

push eventSimenB/jest

Anders Kaseorg

commit sha 3d09c5c0c0f336af2e30f5e2e0252913a5cb36dd

Allow instrumentation of transformed files with non-js file extensions (#9589)

view details

Simen Bekkhus

commit sha 56565cc04c7261c5a3222a0547bea58c024ec0b8

chore: move execution of `setupFiles` to `jest-runner` (#9596)

view details

Simen Bekkhus

commit sha 5dfdd7fe6417a26f2ab151a7ebbfb3bc9973426a

it somehow runs...

view details

push time in 4 days

Pull request review commentfacebook/jest

feat: pass ESM options to transformers

 export default class ScriptTransformer {     fileData: string,     filename: Config.Path,     instrument: boolean,+    supportsDynamicImport: boolean,

potentially we could add separate functions? the es module path can be async (or rather, always is) as well, so that might tie nicely into #9504. Then we could ditch the supportsDynamicImport option since that works for both esm and cjs (and can be async) and just vary on the static version

SimenB

comment created time in 4 days

Pull request review commentfacebook/jest

feat: pass ESM options to transformers

+/**+ * Copyright (c) Facebook, Inc. and its affiliates. All Rights Reserved.+ *+ * This source code is licensed under the MIT license found in the+ * LICENSE file in the root directory of this source tree.+ */++// this is a separate file so it can be mocked in tests+export {loadPartialConfig} from '@babel/core';

no, it uses Object.defineProperty(exports) under the hood, with configurable: false, so it cannot be mutated. I also tried a deep mock of the partial config loader file, but it has some weird async/sync abstraction thing that I didn't understand at all 😅

SimenB

comment created time in 4 days

push eventSimenB/jest

Simen Bekkhus

commit sha 5f6eac4f85226c2aafbec34a8d723dc24cc2b66d

each

view details

push time in 4 days

Pull request review commentfacebook/jest

feat: pass ESM options to transformers

 test(`Returns source string with inline maps when no transformOptions is passed`   expect(result.map).toBeDefined();   expect(result.code).toMatch('//# sourceMappingURL');   expect(result.code).toMatch('customMultiply');-  expect(result.map.sources).toEqual(['dummy_path.js']);-  expect(JSON.stringify(result.map.sourcesContent)).toMatch('customMultiply');+  expect(result.map!.sources).toEqual(['dummy_path.js']);+  expect(JSON.stringify(result.map!.sourcesContent)).toMatch('customMultiply');+});++describe('caller option', () => {+  test('correctly merges from defaults and options', () => {+    babelJest.process(sourceString, 'dummy_path.js', makeProjectConfig(), {+      instrument: false,+      // @ts-ignore+      supportsDynamicImport: true,+      supportsStaticESM: true,+    });++    expect(loadPartialConfig).toHaveBeenCalledTimes(1);+    expect(loadPartialConfig).toHaveBeenCalledWith(+      expect.objectContaining({+        caller: {+          name: 'babel-jest',+          supportsDynamicImport: true,+          supportsStaticESM: true,+        },+      }),+    );++    loadPartialConfig.mockClear();++    babelJest.process(sourceString, 'dummy_path.js', makeProjectConfig(), {

yeah, probably

SimenB

comment created time in 4 days

push eventSimenB/jest

Simen Bekkhus

commit sha 56565cc04c7261c5a3222a0547bea58c024ec0b8

chore: move execution of `setupFiles` to `jest-runner` (#9596)

view details

push time in 4 days

delete branch SimenB/jest

delete branch : setupfiles-out-of-runtime

delete time in 4 days

push eventfacebook/jest

Simen Bekkhus

commit sha 56565cc04c7261c5a3222a0547bea58c024ec0b8

chore: move execution of `setupFiles` to `jest-runner` (#9596)

view details

push time in 4 days

PR merged facebook/jest

Reviewers
chore: move execution of `setupFiles` to `jest-runner` ES Modules cla signed

<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->

<!-- Please remember to update CHANGELOG.md in the root of the project if you have not done so. -->

Summary

Since ESM is asynchronous we cannot run this as part of jest-runtime's constructor.

This is technically a breaking change, but I'd be hugely surprised if someone either uses a custom runtime or uses jest-runtime directly. Can hold off on merging until Jest 26 changes start landing, but that'll make it impossible to land any kind of support for ESM in setupFiles. Maybe not a biggie 🙂

<!-- Explain the motivation for making this change. What existing problem does the pull request solve? -->

Test plan

Green CI

<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->

+44 -58

1 comment

7 changed files

SimenB

pr closed time in 4 days

Pull request review commentfacebook/jest

chore: move execution of `setupFiles` to `jest-runner`

 async function runTestInternal(    const start = Date.now(); +  config.setupFiles.forEach(path => runtime!.requireModule(path));

yeah, makes sense

SimenB

comment created time in 4 days

pull request commentnodejs/docker-node

fix: keep dynamically linked files in slim images

Yeah, failed when gh had issues earlier. I was unable to open a manual pr as well. I'll restart it 🙂

SimenB

comment created time in 4 days

push eventnodejs/docker-node

Simen Bekkhus

commit sha 71849fa34800c2acb7da9c3a283520b2f4d84376

chore: try to keep dynamically linked files

view details

Simen Bekkhus

commit sha 2caaf1a42cdf44e0e50ab30c82415c71bf2f3a21

maybe fix arm?

view details

Simen Bekkhus

commit sha e76dc47a4104a1b06765673dadb56f1855c32cad

Merge pull request #1198 from SimenB/keep-dynamically-linked-files fix: keep dynamically linked files in slim images

view details

push time in 4 days

issue closednodejs/docker-node

image arm32v7/node:13.6-slim not working

Since updating from v13.5 to v13.6 the image arm32v7/node:slim fails starting.

Example: docker run -it arm32v7/node:13.6-slim results in

node: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

closed time in 4 days

khassel

PR merged nodejs/docker-node

fix: keep dynamically linked files in slim images

Should be merged after #1197. I kept them separate as I don't know how to test that this works for arm.

Fixes #1195

+144 -8

5 comments

8 changed files

SimenB

pr closed time in 4 days

issue commentfacebook/jest

jest Symbol equality is broken

The issue in the OP is fixed, and the other issue can be tracked at #6466

itaied246

comment created time in 4 days

issue closedfacebook/jest

jest Symbol equality is broken

bug?

What is the current behavior?

jest equality for object with Symbol key is broken.

{ } == { [Symbol("jest")]: 2 }

Example

What is the expected behavior?

{ } != { [Symbol("jest")]: 2 }

closed time in 4 days

itaied246

issue closedfacebook/jest

mock of third-party constructor function contains no instance methods

I'm working on an authentication wrapper that delegates to the 'keycloak-js' package, which exposes a constructor function.

Following the documentation on mocking ES6 classes, I import the Keycloak constructor, call jest.mock('keycloak-js') and then run my tests.

While the constructor mock works, and I can verify that it's being called, the resulting Keycloak instance has no methods on it which causes my wrapper to fail with TypeError ... is not a function..

Current behavior: Mocking the Keycloak library creates an instance with no methods on it.

Expected behaviour: Mocking the Keycloak library creates an object identical to a true Keycloak instance, but where each method returns undefined.

How to reproduce: repo: https://github.com/tjlahr/faillingKeycloakTest Clone and install the repo & run the test. It fails.

System: OS: macOS Sierra 10.12.6 CPU: x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz Binaries: Node: 8.9.1 Yarn: Not Found npm: 5.7.1 npmPackages: jest: wanted: ^23.0.0-alpha.0 installed: 23.0.0-alpha.0

Note

I don't necessarily expect Jest to handle ANY third-party library, but I'm curious to know more about what in particular is not working here.

The basic module structure is as follows and seems like a reasonable pattern to support.

(function() {
  var Keycloak = function () {
    this.someInstanceMethod = function() {};
  }

  module.exports = Keycloak;
})()

closed time in 4 days

tjlahr

issue commentfacebook/jest

mock of third-party constructor function contains no instance methods

It seems the reproduction repo has been deleted. If this is still not working, please open up a new issue

tjlahr

comment created time in 4 days

issue closedfacebook/jest

jest's `require` doesn't keep globals set by vm.runInContext

Do you want to request a feature or report a bug? a bug

STR

  1. Clone and install https://github.com/julienw/jest-vm-issue
  2. run npm test

Expected:

  • Both tests pass.

Actual:

  • Both tests fail.

I use:

  • node 7.10.0
  • npm 4.2.0
  • jest 20.0.4

Jest is only configured with verbose: true.

In the STR we run require('./script') in vm.runInContext. The goal is to properly control the globals for this script.

The larger goal is to simulate a web worker environment because our worker is made of several modules and is supposed to be built with with webpack before usage, that's what I'd like to avoid with this fake-worker implementation.

closed time in 4 days

julienw

issue commentfacebook/jest

jest's `require` doesn't keep globals set by vm.runInContext

I don't understand what the issue is? Running that code behaves the same in Node as it does in both test envs (beyond jsdom having has window ? true while node test env and proper node have false). When you inject require from one context it doesn't evaluate modules in a different context automatically, you need to implement require yourself for this to work

julienw

comment created time in 4 days

issue commentnodejs/node

Evaluate node core modules within a `vm.Context`

Ah okay, thanks for elaborating! The use case in the OP should be perfectly fine with that limitation, then.

As for globals in user code, that limitation would present issues for us I think. For example our require implementation is passed from the parent context. The example in the OP is a bit too simplified perhaps, instead compiledFunction(require) what we really do is compiledFunction(ourCustomRequireImplementation), and that function needs to be created from the outside. We'll also want to control (and replace dynamically) setTimeout and friends from the parent context for mocked timers. I'm personally fine with the function we pass in not being instanceof Function (as it's not today anyways), but that might not be a trade-off that core can make or limitation it can accept if adding a new API for this?

However, the code snippet I linked to would not be affected as in that case we just want what's inside the context to look like what's outside - we don't actually need to know what they are or access them.

SimenB

comment created time in 4 days

pull request commentfacebook/jest

fix: improve open handles detection

I think it might be best to show keep the ones that are deleted, but mark them as closed - that way if some async thing that async started something that's hanging but itself is closed (like the server example that CI caught) would still be visible, although it'd be noisier in the output

SimenB

comment created time in 4 days

issue commentfacebook/jest

--detectOpenHandles not showing any message even test not finished completely.

A proper reproduction we can pull down and run. I can almost guarantee anything that's not git clone && yarn && yarn test (possibly with a docker run before test if it needs to connect to something, and npm is of course fine) will not be very helpful.

https://github.com/facebook/jest/issues/6937#issuecomment-500886506 packaged up in a repository might work. https://github.com/facebook/jest/issues/6937#issuecomment-562861333 doesn't reproduce for me.


Note that I have an open PR that improves this (#9532), however it makes certain simpler caser worse. Need to figure out the correct balance. Probably some sort of heading saying which were collected in case it helps track down others. So more false positives, but also higher chance of not missing the ones that are real

whitesnow9291

comment created time in 4 days

Pull request review commentfacebook/jest

feat: pass ESM options to transformers

 export default class ScriptTransformer {     fileData: string,     filename: Config.Path,     instrument: boolean,+    supportsDynamicImport: boolean,

should ideally use options objects, as 2-3 boolean flag inputs are quite confusing

SimenB

comment created time in 4 days

Pull request review commentfacebook/jest

feat: pass ESM options to transformers

 export default class ScriptTransformer {     fileData: string,     filename: Config.Path,     instrument: boolean,+    supportsDynamicImport: boolean,

I made them non-optional for all private methods and default false for the public ones

SimenB

comment created time in 4 days

Pull request review commentfacebook/jest

feat: pass ESM options to transformers

     {"path": "../jest-snapshot"},     {"path": "../jest-source-map"},     {"path": "../jest-test-result"},+    {"path": "../jest-transform"},

this was missing, leading to some weird inconsistencies in type error reporting 🤷‍♂

SimenB

comment created time in 4 days

push eventSimenB/jest

Simen Bekkhus

commit sha 64dba1501ff8d5ab040af8a44829a7937aa114be

oops

view details

Simen Bekkhus

commit sha c4d4cecbe0253d0999b17c8e3109c2c7a9838751

update snaps

view details

push time in 4 days

push eventSimenB/jest

Simen Bekkhus

commit sha 5c5976c58646386a0eaa2f66c774287d93fb2b8f

in instrument file as well

view details

push time in 4 days

push eventSimenB/jest

Simen Bekkhus

commit sha ce97aac2ead1fc42395610102a78b76bc634a1f2

link to PR

view details

push time in 4 days

PR opened facebook/jest

Reviewers
feat: pass ESM options to transformers ES Modules

<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->

<!-- Please remember to update CHANGELOG.md in the root of the project if you have not done so. -->

Summary

When jest-runtime supports ESM, then babel can leave those statements alone. While not usable yet, this helps reduce the eventual diff for ESM.

Test plan

Added some unit tests to some funky merging code, otherwise this is not really testable until we land more ESM stuff. While it's all added as optional to avoid a breaking change, jest-runtime explicitly opts out if it, ao no real way of triggering this.

+204 -24

0 comment

9 changed files

pr created time in 4 days

create barnchSimenB/jest

branch : pass-esm-options-to-transformers

created branch time in 4 days

push eventfacebook/jest

Anders Kaseorg

commit sha 3d09c5c0c0f336af2e30f5e2e0252913a5cb36dd

Allow instrumentation of transformed files with non-js file extensions (#9589)

view details

push time in 4 days

PR merged facebook/jest

Allow instrumentation of transformed files with weird file extensions cla signed

Summary

The default configuration of babel-plugin-istanbul only allows instrumentation of files with extensions .js, .cjs, .mjs, .ts, .tsx, .jsx (https://github.com/istanbuljs/schema/blob/v0.1.2/index.js#L71). However, we know that we’re running it on code that we just transformed to JavaScript, so the source language no longer matters, and we should disable this check to get complete instrumentation.

Test plan

With the example project at https://github.com/andersk/jest-handlebars-test, before:

$ jest --coverage --no-cache
 PASS  __tests__/greet.js
  ✓ am (3ms)

----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
----------|---------|----------|---------|---------|-------------------
All files |       0 |        0 |       0 |       0 |                   
----------|---------|----------|---------|---------|-------------------
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.443s
Ran all test suites.

and after:

$ jest --coverage --no-cache
 PASS  __tests__/greet.js
  ✓ am (4ms)

-----------|---------|----------|---------|---------|-------------------
File       | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
-----------|---------|----------|---------|---------|-------------------
All files  |      75 |    66.67 |   66.67 |   66.67 |                   
 greet.hbs |      75 |    66.67 |   66.67 |   66.67 | 4                 
-----------|---------|----------|---------|---------|-------------------
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.551s
Ran all test suites.
+158 -0

9 comments

9 changed files

andersk

pr closed time in 4 days

PR opened DefinitelyTyped/DefinitelyTyped

Reviewers
[@babel/core]: add `supportsDynamicImport`

Please fill in this template.

  • [x] Use a meaningful title for the pull request. Include the name of the package modified.
  • [x] Test the change in your own code. (Compile and run.)
  • [ ] Add or edit tests to reflect the change. (Run with npm test.)
  • [x] Follow the advice from the readme.
  • [x] Avoid common mistakes.
  • [ ] Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

  • [x] Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/babel/babel/pull/10109
  • [ ] If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
  • [ ] If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.
+1 -0

0 comment

1 changed file

pr created time in 4 days

push eventSimenB/DefinitelyTyped

Simen Bekkhus

commit sha e3f3cb7b49d4a8606015b6f77cf6e1a27d9c38c1

[@babel/core]: add `supportsDynamicImport`

view details

push time in 4 days

more