Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting an Namespace 'NodeJS' has no exported member 'Global' error #11640

Closed
robgeurden opened this issue Jul 5, 2021 · 17 comments 路 Fixed by #11645
Closed

Getting an Namespace 'NodeJS' has no exported member 'Global' error #11640

robgeurden opened this issue Jul 5, 2021 · 17 comments 路 Fixed by #11645

Comments

@robgeurden
Copy link

馃悰 Bug Report

When trying to build our solution we get the following error:
Namespace 'NodeJS' has no exported member 'Global' on line node_modules/@jest/types/build/Global.d.ts:85:62

Seems to be coming from https://github.com/facebook/jest/blob/master/packages/jest-types/src/Global.ts line 137

To Reproduce

Version of node 14.16.1 & Jest 27.0.6

Expected behavior

Not to get this error when building

Link to repl or repo (highly encouraged)

https://github.com/robgeurden/easy-test

@sachinahya
Copy link

We just came across this too when our CI builds started failing. Looks like NodeJS.Global namespace was removed in @types/node 16.0.0 and @jest/types is broken because it specifies any version in its package.json.

Managed to work around it by adding "@types/node": "^15.14.1" to our package.json dependencies.

@SimonSchick
Copy link

NodeJS.Global should probably be replaced w/ typeof globalThis

@splincode
Copy link
Contributor

hello, I have a problem with it

@mrcnski
Copy link

mrcnski commented Jul 12, 2021

Can a maintainer please provide an update on this? This is causing ecosystem-wide disruption. I've documented only a few instances here. Someone has graciously provided a fix here yet official maintainers have been silent.

Also, what is being done to ensure that this does not occur again in the future?

@nyan-left
Copy link

Also experiencing this issue.

@SimonSchick
Copy link

If this issue isn't addressed by tomorrow I will work on adding a a small compatibility layer to v16, the preferred approach however is for people to to stick to v15 for now.

@aterreno
Copy link

Just hit this as well after upgrading to jest 27 from jest 26

@fouchekeagan
Copy link

I worked around this by adding "@types/node@15.12.2" as a dependency.
Command: npm i @types/node@15.12.2 --save-dev

image

Using Jest 27:
image

I hope this helps someone until the issue is resolved. :)

@aterreno
Copy link

@fouchekeagan yep that's exactly how we fixed it, if you are on node types @16 it won't work thanks for sharing

myrotvorets-team added a commit to myrotvorets/facex-base that referenced this issue Jul 22, 2021
mikkopiu added a commit to espoon-voltti/evaka that referenced this issue Jul 22, 2021
- I've been to hell and back, and haven't managed to pinpoint all of the exact dependencies that cause the build to leak (or more likely: attempt to over-allocate) memory but after extensive testing, this is the set of dependencies that manages to build in an environment with max 3GB of memory available
    - It could very well be that some of the dependencies blocked by this commit's locks simply take the build's memory consumption over the 3GB limit and aren't part of the same issue of over allocating memory -- but this is a decent compromise that ensures that the build should no longer intermittently fail in CI (which has 4GB, of which roughly 3,3GB is usable)
- The test setup:
    - `docker run --rm -it --volume $(pwd):/home/circleci/project --memory=3G cimg/node:14.15` (same image as in CI, and 3 GB of memory ensures that the build will always work on the 4 GB available in CI)
        1. `cd .. && cp -r project frontend` (just to ignore any file permission issues without touching the executor image too much)
        2. `rm -rf dist node_modules`
        3. `yarn install --immutable`
        4. `yarn build`
        5. -> repeat at least 3 times and if all pass (& CI passes) -> OK set of dependency versions
    - 8 parallel CI jobs running to increase sample size with `/sys/fs/cgroup/memory/memory.max_usage_in_bytes` logged
- Findings:
    - _Something_ (or a combination of things) attempts to over allocate memory (specifically new heap space) when running with `master`'s versions of frontend dependencies (likely culprits described below)
        - With the versions used in this commit, the build will use all memory available to it but GC is early enough to never actually go over the limit **but** something in the newer dependencies goes over the line, causing reaping of the build processes and crashing the build
        - The most likely explanation would be something "outside" the Node.js process (i.e. something creates additional processes), which doesn't obey the same heap limits
    - TypeScript 4.3 has a few issues with relating to complex types which lead to at least significantly higher memory usage (likely not the same over-allocation issue as below) -> **lock to ~4.2.x**
        - Related: microsoft/TypeScript#44299 and microsoft/TypeScript#44281
        - This is actually a good idea anyway as TS makes breaking changes in "minor" releases (e.g. 4.2.x -> 4.3.x) and we shouldn't blindly update it
    - webpack's dependency `terser-webpack-plugin@5.1.2` updates `jest-worker` 26 -> 27 which appears to cause memory over allocation, likely related to the way it creates new processes and/or threads for workers based on incorrect assumptions about the available amount of CPU cores inside a Docker container (`os.cpus()` vs. what's actually allocated in cgroups) -> **lock to 5.1.1**
        - There's also a big issue with shared dependencies with `@storybook/*` modules also using webpack (but *4.x.x* instead of 5.x.x), which makes using `resolutions` pretty difficult without locking absolutely everything
        - Related: webpack/webpack#13550 and webpack-contrib/terser-webpack-plugin#403
    - `@types/node@16.x.x` is incompatible with Jest 27 (jestjs/jest#11640) -> update only to 15.x.x
    - `webpack@5.38.0` updates _some_ dependency that either causes a similar memory over-allocation or simply increases the build's memory usage over the set 3GB limit
        - My money's on `webpack-sources` as based on webpack's changelogs it appears to have had some memory leak issues between the versions used by `webpack@5.37.1` and `webpack@5.46.0` (latest at the time of this commit)
     - `ts-node@10.x.x` could also be related but didn't manage to find anything conclusive here
- Additionally, update all dependencies _that don't break the build / cause memory issues_ to the latest non-major versions
    - Excluded Chart.js (& related) dependencies as that whole repo seems in a very weird place now
        - 3.x.x released a while ago and there hasn't been any release notes, tags or anything
        - 3.0.0 diff is pretty massive with very non-descriptive commit/PR messages
    - Excluded `react-select` and `react-datepicker` as they're going to be dropped at some point and both of them appeared to have pretty major changes
    - Excluded Testcafe as that's always a pain & we're going to drop it when everything's been re-written for Playwright
    - Update webpack loaders to their latest (incl. major) versions -- nothing breaking for us
@sandersn
Copy link

sandersn commented Jul 27, 2021

NodeJS.Global is exported in five places:

jest-fake-timers: legacyFakeTimers.ts
jest-fake-timers: modernFakeTimers.ts
jest-types/src/Config.ts
jest-types/src/Global.ts
jest-mock/src/index.ts

But there are quite a few more in the tests.

globalThis was introduced in Typescript 3.4, March 2019. TS 3.3 is outside the 2-year support window for Definitely Typed (which is why I ran into it -- everything on DT needs to support @types/node@16), although I'm not sure what versions jest tries to support.

Edit: I tried upgrading jest to node 16 types but got stuck (1) because of other node 16 changes (2) the difference between places that accept either globals or Window, or require both globals and Window.

@ghost
Copy link

ghost commented Aug 4, 2021

NodeJS.Global should probably be replaced w/ typeof globalThis

interface CustomNodeJsGlobal extends NodeJS.Global {
  foo: {
    bar: string | null
  }
}

@SimonSchick How'd you do it?

@SimonSchick
Copy link

global { // declarations }, pls see the typescript manual.

@signal-intrusion
Copy link

signal-intrusion commented Aug 4, 2021

@SimonSchick I may have misunderstood. The fix has been shipped?

I was only able to make this work by installing @types/node@15.x. I've read the relevant typescript docs many times and tried many, many permutations (https://www.typescriptlang.org/docs/handbook/declaration-files/templates/global-d-ts.html).

I want to type this:

// file.ts
global.thing = {
        logging: new Logger(),
        version: version
}

This is the original global.d.ts, which works in @types/node@15:

// global.d.ts
declare global {
    module NodeJS {
        interface Global {
            thing: {
                logging: Logger,
                version: string
            }
        }
    }
}

With @types/node@16 I get the following error: Element implicitly has an 'any' type because type 'typeof globalThis' has no index signature.

Things I've tried:

declare global {
    interface globalThis {
        thing: {
            logging: Logger,
            version: string
        }
    }
}

declare global {
    interface thing {
        logging: Logger,
        version: string
    }
}

declare global {
    interface Global {
        thing: {
            logging: Logger,
            version: string
        }
    }
}

interface thing: {
    logging: Logger,
    version: string
}

// etc.

(global as Global).thing = {
        logging: new Logger(),
        version: version
}

(global as globalThis).thing = {
        logging: new Logger(),
        version: version
}

(global as Window).thing = {
        logging: new Logger(),
        version: version
}

I've been at this for a few hours now and I just can't figure it out.

I mean @types/node@15 works and so does: (global as unknown as Window).thing = {} 馃し

@SimonSchick
Copy link

All global MUST be declared w/ var eg.

declare global {
  var myGlobal: number;
}

Please read the documentation

@G-Rath
Copy link
Contributor

G-Rath commented Aug 5, 2021

I feel like we might have gotten a bit sidetracked, so looping back around to the original error:

@SimonSchick you said previously:

If this issue isn't addressed by tomorrow I will work on adding a a small compatibility layer to v16

Did you end up doing this? I can't see any strong evidence that you did, and for me type checking is still broken using the latest v16 types, but wanted to double check in case I'd missed something.

I've been able to resolve the problem locally with the following:

declare global {
  namespace NodeJS {
    interface Global {}
  }
}

Which should suffice as a temporary workaround to allow compiling & typechecking in downstream projects.

@waynevanson
Copy link

I've been able to resolve the problem locally with the following:

declare global {
  namespace NodeJS {
    interface Global {}
  }
}

Which should suffice as a temporary workaround to allow compiling & typechecking in downstream projects.

I had to do the following to get mine to work, as I'm building a custom reporter and preset.

// https://github.com/facebook/jest/issues/11640#issuecomment-893867514
declare global {
  namespace NodeJS {
    interface Global {}
    interface InspectOptions {}

    interface ConsoleConstructor
      extends console.ConsoleConstructor {}
  }
}

myrotvorets-team added a commit to myrotvorets/facex that referenced this issue Aug 11, 2021
myrotvorets-team added a commit to myrotvorets/facex-base that referenced this issue Aug 11, 2021
@SimenB SimenB linked a pull request Aug 13, 2021 that will close this issue
mrienstra added a commit to mrienstra/playwright that referenced this issue Sep 5, 2021
mrienstra added a commit to mrienstra/jest that referenced this issue Sep 5, 2021
The `playwright` repo uses `expect`, I'd like to bump the version they're using from `26.4.2` to `27.1.0`. Here is the issue which motivated this change: jestjs#11640

You can see my proposed changes here:
microsoft/playwright@master...mrienstra:patch-3

I haven't opened a PR for those changes yet, hoping to land this one first.

Playwright `npm check-deps` runs `utils/check_deps.js`, which contains a function `allowExternalImport` / `alllowExternalImport` (very recently added in microsoft/playwright#8501), which has a problem with the `expect` `package.json` `exports`, thus the motivation for this PR.
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.