Initial support for module: node12 #44501

weswigham · 2021-06-08T04:57:20Z

This PR adds the basic framework for (compiler options and defaults) and core emit behavior for a new module: node12 and module: nodenext compiler option. Both should be almost identical, for now.

The core of this PR is allowing .js and .ts files to be interpreted as either esm or cjs format files, within the same compilation.

The esm emit branch is identical to es2020+ module emit, except we transpile TS-style import = require statements down to a helper-like createRequire call, rather than error'ing and eliding them. (This gives easy access to sync require statements as-needed for, eg, conditional top-level access to cjs dependencies)
The cjs emit branch modifies normal cjs emit to preserve import call expressions as-is, this way they can be used to pull in async (esm) dependencies within cjs-targeted files, and is otherwise normal cjs output.
Since we don't currently actually read in non-ts and non-js extensions (yet - that'll be a followup pull request), the mode of the .ts or .js file is determined by the enclosing package.json and its type field (if it is present and set to module, .ts and .js files are esm format, otherwise they are cjs format).

As far as checking goes, both options imply esModuleInterop for now (this only really affects default import checking and cjs module emit and may be subject to change when more checker behaviors are added later if they pickup the work this flag does). Additionally, module: node12 implies a moduleResolution: node12 and target: es2020, and module: nodenext implies a moduleResolution: nodenext and target: esnext. The new moduleResolution modes currently just redirect to the old node resolution mode until they're actually implemented in another PR.

Also included is a driveby fix for js declaration emit where export {default} from "fs"; in js was mistakenly serialized to export {"fs" as default} from "fs"; in a declaration file when "fs" is just a shorthand module declaration.

weswigham · 2021-06-08T04:57:30Z

@typescript-bot pack this

typescript-bot · 2021-06-08T04:57:46Z

Heya @weswigham, I've started to run the tarball bundle task on this PR at 00d3e60. You can monitor the build here.

typescript-bot · 2021-06-08T05:16:25Z

Hey @weswigham, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/104705/artifacts?artifactName=tgz&fileId=481F6DA0E8E4327055734581079A1C759EB09FE0C4041C50E8A0F65A8B9676F202&fileName=/typescript-4.4.0-insiders.20210608.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.4.0-pr-44501-2".;

weswigham · 2021-06-14T22:08:13Z

@typescript-bot pack this

typescript-bot · 2021-06-14T22:08:15Z

Heya @weswigham, I've started to run the tarball bundle task on this PR at 632b495. You can monitor the build here.

weswigham · 2021-06-14T22:12:45Z

@typescript-bot test this

typescript-bot · 2021-06-14T22:12:46Z

Heya @weswigham, I've started to run the extended test suite on this PR at 632b495. You can monitor the build here.

typescript-bot · 2021-06-14T22:28:23Z

Hey @weswigham, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/104964/artifacts?artifactName=tgz&fileId=1B21432CD9A5F605C89C976D8B4E5AE17B6882129C5341748B3F95D68561BDA202&fileName=/typescript-4.4.0-insiders.20210614.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.4.0-pr-44501-7".;

weswigham · 2021-06-14T22:34:33Z

@typescript-bot test this

typescript-bot · 2021-06-14T22:34:35Z

Heya @weswigham, I've started to run the extended test suite on this PR at 632b495. You can monitor the build here.

andrewbranch

A couple questions; the comment in esnextAnd2015.ts is the only one blocking for me.

andrewbranch · 2021-06-17T18:55:46Z

src/compiler/program.ts

+            const parts = getPathComponents(fileName);
+            parts.pop();
+            while (parts.length > 0) {
+                const pkg = getPackageJsonInfo(getPathFromPathComponents(parts), /*onlyRecordFailures*/ false, state);
+                if (pkg) {
+                    return pkg.packageJsonContent?.type === "module" ? ModuleKind.ESNext : ModuleKind.CommonJS;
+                }
+                parts.pop();
+            }


Any reason not to use forEachAncestorDirectory?

andrewbranch · 2021-06-17T19:00:15Z

src/compiler/program.ts

+                return undefined;
+        }
+        function lookupFromPackageJson(): ModuleKind.ESNext | ModuleKind.CommonJS {
+            const state: {


Nit: if getPackageJsonInfo is going to be exported, it might be nice if its parameter types (ModuleResolutionState) were too. Alternatively, Parameters<typeof getPackageJsonInfo>[2]?

andrewbranch · 2021-06-17T19:11:34Z

src/compiler/transformers/module/esnextAnd2015.ts

+                    // Though an error in es2020 modules, in node-flavor es2020 modules, we can helpfully transform this to a synthetic `require` call
+                    // To give easy access to a synchronous `require` in node-flavor esm. We do the transform even in scenarios where we error, but `import.meta.url`
+                    // is available, just because the output is reasonable for a node-like runtime.
+                    return getEmitScriptTarget(compilerOptions) >= ModuleKind.ES2020 ? visitImportEqualsDeclaration(node as ImportEqualsDeclaration) : undefined;


Maybe the comment is trying to explain this, but I’m not getting it: why wouldn’t we make this dependent upon a node12+ module rather than the script target? This isn’t going to produce anything useful for browser-bound ES2020 modules, right?

Well, we'll issue an error on this import form in non-node es2020+, we're just choosing to emit the node-style transpilation, rather than omit the erroneous node, since the node-style transpilation is still pretty reasonable (and could actually work on other runtimes if they're providing a cjs interop layer).

Got it. I really like the createRequire helper, by the way. That’s kind of a pain in vanilla JS.

andrewbranch · 2021-06-17T19:39:35Z

src/compiler/types.ts

@@ -6099,7 +6119,11 @@ namespace ts {
        //       module kind).
        ES2015 = 5,
        ES2020 = 6,


Just to make sure I have the distinction correct: ES2015–ESNext are the correct setting for ESM in browsers, right? And possibly in other non-Node JS runtimes (but those are likely to layer their own ideas on top, like Node)? But we lack a corresponding module resolution mode that actually does the right thing for them?

Yeah. We don't have a module resolution mode that understands URLs at all, so classic mode is as close as we get.

As an example/datapoint, GJS (JavaScript for GNOME) supports ESM so our projects would likely use the ES2015-ESNext module settings.

We support either a root-level command line flag (-m/--module), a root-level API (gjs_evaluate_module), or treat all dynamic imports (import('./x.js')) as ESM (regardless of extension).

andrewbranch · 2021-06-17T20:10:24Z

src/compiler/checker.ts

@@ -7141,8 +7168,10 @@ namespace ts {
                    if (!target) {
                        return;
                    }
-                    let verbatimTargetName = unescapeLeadingUnderscores(target.escapedName);
-                    if (verbatimTargetName === InternalSymbolName.ExportEquals && (compilerOptions.esModuleInterop || compilerOptions.allowSyntheticDefaultImports)) {
+                    // If `target` refers to a shorthand module symbol, the name we're trying to pull out isn;t recoverable from the target symbol


This is the drive-by fix, right? What’s a shorthand module symbol?

Suggested change

// If `target` refers to a shorthand module symbol, the name we're trying to pull out isn;t recoverable from the target symbol

// If `target` refers to a shorthand module symbol, the name we're trying to pull out isn't recoverable from the target symbol

It's a (member of a) declare module "foo"; defined module.

sandersn

I don't have any useful comments, just a lot of typos. :)

src/compiler/types.ts

sandersn · 2021-06-21T23:50:58Z

src/compiler/program.ts

+     * `options` parameter.
+     *
+     * @param fileName The normalized absolute path to check the format of (it need not exist on disk)
+     * @param packageJsonInfoCache (Optional) A cache for package file lookups - it's best to have a cache when this function is called often


Suggested change

* @param packageJsonInfoCache (Optional) A cache for package file lookups - it's best to have a cache when this function is called often

* @param [packageJsonInfoCache] A cache for package file lookups - it's best to have a cache when this function is called often

(it also might make sense to put this parameter last)

sandersn · 2021-06-22T00:02:11Z

src/compiler/types.ts

+         * since it switches the builtin `node` module transform. Generally speaking, if unset,
+         * the field is treated as though it is `ModuleKind.CommonJS`.
+         */
+        impliedNodeFormat?: ModuleKind.ESNext | ModuleKind.CommonJS;


is there a nodeFormat property already? Would it be possible to call this nodeFormat? Does that name imply more certainty than this one?

no.... nodeFormat just sounds like it might have something to do with ts.Node (since it's a property on one), while the extra word implied I'm hoping makes it more at-a-glance apparent that it has something to do with node-the-platform.

sandersn · 2021-06-22T00:14:36Z

src/compiler/types.ts

@@ -5894,7 +5908,13 @@ namespace ts {

    export enum ModuleResolutionKind {
        Classic  = 1,
-        NodeJs   = 2
+        NodeJs   = 2,
+        // Starting with node12, node's module resolver has significant departures from tranditional cjs resolution


Does this comment show up in the quick info of our API? If not, I think we could do with a shorter comment for future maintainers.

No, it doesn't show up in our public API - it's more of a rationale comment than anything else.

src/compiler/types.ts

src/compiler/transformers/module/esnextAnd2015.ts

andrewbranch

I just remembered—everything that looks at UsersPreferences["importModuleSpecifierEnding"] needs to completely ignore that setting and pretend it’s always "full" when --moduleResolution is node12 or nodenext. That setting is only applicable in modes where foo, foo/index, and foo/index.js are plausibly interchangeable. As it is now, I believe auto imports and string completions will default to leaving off extensions and index filenames, which won’t resolve in node-style module resolution.

weswigham · 2021-06-23T00:02:56Z

@andrewbranch considering this doesn't add any of the new resolution rules yet (except format detection), I think that's probably fine to leave as-is until those are in place.

andrewbranch · 2021-10-13T00:09:53Z

@renke it sounds like your watch mode issue was just filed at #46333

benjie · 2021-11-10T14:32:13Z

Hello, your beta announcements are asking for feedback on this feature. First of all - I'm super excited about this! Great work!

One thing I was really looking forward to in Node.js exports/ESM support was having example files that import from the library itself - this way we can just say import { foo } from "my-module" rather than import { foo } from ".." /* TODO: replace this with "my-module" */ - makes it much easier for users to copy/paste examples whilst keeping the examples co-located inside the package.

Node.js supports this "self-referencing" behaviour; however TypeScript doesn't seem to understand how to import this in module:"nodenext" mode - a could not find a declaration file for module 'my-module' error is raised.

I've prepared a minimal reproduction here with js folder working using Node.js and analogous ts folder which is not working with TypeScript (won't compile):

https://github.com/benjie/typescript-self-referencing-issue

TSConfig:

{
  "compilerOptions": {
    "lib": ["es2021"],
    "module": "nodenext",
    "target": "es2021",

    "strict": true,

    "rootDir": "src",
    "declaration": true,
    "declarationDir": "dist",
    "outDir": "dist"
  },
  "include": ["src"],
  "exclude": ["dist"]
}

TypeScript version 4.6.0-dev.20211110

Maybe this relates to #46212?

Thanks for your hard work on TypeScript ❤️

andrewbranch · 2021-11-10T17:16:29Z

@benjie thanks for the feedback! It works after you do a build once and dist/index.d.ts is present. I think this is a bug—it seems like we need to map back from outDir to the root. I’ve copied your report to #46762.

benjie · 2021-11-10T21:37:01Z

Thanks @andrewbranch! When I did a second build afterwards it told me I was trying to overwrite source files; I tried adding exclude but that didn’t solve it.

arpowers · 2021-11-26T16:21:18Z

@orta on the topic of extensions, there needs to be more clarification about how to handle things during development. Specific questions:

The import/no unresolved eslint rule complains about the file not existing, recommend just disabling that rule?
Due to this change/standardization of convention regarding file extensions, what is a good general way of "always" handling extensions across a large TS project? (working across both browser and node)

loynoir · 2021-12-06T16:54:56Z

sugar import = require to require-or-createRequire and allow try-catch?

import WebStream = require('stream/web') ?? require('web-streams-polyfill/dist/ponyfill.js')

try {
  require('stream/web')
} catch {
  require('web-streams-polyfill/dist/ponyfill.js')
}

nayeemrmn · 2022-08-06T18:44:14Z

Hello, one of the features gated by "moduleResolution": "nodenext" is the per-export types mentioned at https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing.

Basically if a dependency has a package.json like:

{
  "exports": {
    "./subpath": {
      "import": "./esm/subpath/index.js",
      "require": "./commonjs/subpath/index.js",
      "types": "./types/subpath/index.d.ts"
    }
  }
}

the "types" field above will not be looked up by a user of that dependency unless they have "moduleResolution": "nodenext" in their tsconfig.

Would the team be open to extending this feature to "moduleResolution": "node"? It's difficult that a library opting into the exports["subpath"].types feature extends a config requirement to its users. Sure that's the point of "moduleResolution" but I noticed that the other features gated by "moduleResolution": "nodenext" are more in the spirit of organising your own code. I think this would be very non-breaking in practice.

reverse ref denoland/dnt#205

weswigham · 2022-08-06T19:36:17Z

No. Old node (ie, pre 12), doesn't support exports. So it won't be getting support for resolution features the matching runtime doesn't have. :)

As is, our checking is actually very useful for indicating if and how a package, as written, will work on the targeted module runtime. (Which, y'know, it might not)

See #50153 for what we're actually thinking about doing - we know stuff like deno wants more flexible resolution, but we're not going to reduce safety for people using other platforms to achieve it.

(Also, as an aside, that example export map, while vaguely functional, is incomplete - it shares types between two formats of entry points, which will create subtle (or not so subtle if the types are esm format) bugs on cross format-interop checking. Each of the require and import conditions should have it's own nested types entry. Rule of thumb: one js file, one .d.ts file. No being cute and trying to share (though you may re-export cjs format types from esm ones pretty easily). Also, order matters - conditions are matched in order, so if require or import or default or node comes before types, we'll never look at the types location, because a prior condition matched. This is export map spec'd behavior, so try not to blame us - you can't resolve compound (nested) conditions and null mappings without this behavior.)

nayeemrmn · 2022-08-06T23:16:03Z

See #50153 for what we're actually thinking about doing - we know stuff like deno wants more flexible resolution, but we're not going to reduce safety for people using other platforms to achieve it.

No worries, some conflation there as it's not a Deno concern at all but just a quirk of dnt's current exports generation (for node) that made me notice this. Fair points otherwise. To pivot slightly, the default "moduleResolution" value will eventually be one that supports exports, right? And if it's not breaking for TS, having the default match the latest version of Node seems logical to me since Node's resolution isn't designed to break as well.

(Also, as an aside, that example export map, while vaguely functional, is incomplete - it shares types between two formats of entry points, which will create subtle (or not so subtle if the types are esm format) bugs on cross format-interop checking. Each of the require and import conditions should have it's own nested types entry.

I got that from https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing. Is there a syntax for giving different types to each condition?

weswigham · 2022-08-07T02:47:03Z

the default "moduleResolution" value will eventually be one that supports exports, right?

The tsc --init default will probably be updated soonish, maybe. We'll probably discuss it after we handle that issue I linked. The compiler default we may change, but likely on a much longer timescale, since it's a breaking change.

weswigham · 2022-08-07T02:53:55Z

I got that from

@DanielRosenwasser can we get that example in the beta post fixed for googleability? I thought we did ages ago (maybe we only fixed it in the release post) - it should be

// package.json
{
    "name": "my-package",
    "type": "module",
    "exports": {
        ".": {
            // Entry-point for `import "my-package"` in ESM
            "import": 
                // Entry-point for TypeScript resolution
                "types": "./types-esm/index.d.ts"
                 // Runtime entry-point
                "default": "./esm/index.js"
            },

            // Entry-point for `require("my-package") in CJS
            "require": {
                // Entry-point for TypeScript resolution
                "types": "./types-cjs/index.d.cts"
                 // Runtime entry-point
                "default": "./commonjs/index.cjs"
            },
        },
    },

    // CJS fall-back for older versions of Node.js
    "main": "./commonjs/index.cjs",

    // Fall-back for older versions of TypeScript (will usually be treated as cjs by older TS)
    "types": "./types-esm/index.d.ts"
}

nayeemrmn · 2022-08-07T12:52:35Z

Also I got to the 4.5 beta release post from https://www.typescriptlang.org/tsconfig#moduleResolution, that should be upgraded to the 4.7 release post.

lgarron · 2022-08-07T23:54:46Z

The compiler default we may change, but likely on a much longer timescale, since it's a breaking change.

I’m really looking forward to this point, since it will allow me as a library author to simplify and deduplicate some “gotcha” workarounds. Is there an appropriate place to track this/would it be alright to file a new issue for that?

weswigham · 2022-08-08T00:16:56Z

I don't think we have an issue tracking it, it's just something we're keeping at the back of our minds.

thw0rted · 2022-08-08T12:18:22Z

Rule of thumb: one js file, one .d.ts file

@weswigham what does that mean for community-maintained packages in DefinitelyTyped? Say we're typing a CJS library that starts shipping both module formats using exports, but continues to avoid shipping in-package type defs. Should the corresponding @types package ship an exports field with separate .d.ts files under exports.import.types and exports.require.types?

ETA: it would be super helpful to point to a random package on DT that does this the "right" way already.

Even though the TS docs and following comment say it's just a fallback :/ microsoft/TypeScript#44501 (comment)

weswigham requested review from DanielRosenwasser and rbuckton June 8, 2021 04:57

typescript-bot assigned weswigham Jun 8, 2021

typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jun 8, 2021

SimenB mentioned this pull request Jun 8, 2021

Jest fails to load jest.config.ts in a ESM project using ts-node 10 jestjs/jest#11453

Closed

veikkoeeva mentioned this pull request Jun 8, 2021

Ethers and Rollup ethers-io/ethers.js#1179

Closed

panva mentioned this pull request Jun 12, 2021

Add top-level exports for all API's panva/jose#202

Closed

andrewbranch mentioned this pull request Jun 17, 2021

importModuleSpecifierEnding changes .ts string completions to .js #44602

Merged

andrewbranch requested changes Jun 17, 2021

View reviewed changes

andrewbranch approved these changes Jun 18, 2021

View reviewed changes

orta mentioned this pull request Jun 19, 2021

Add flag to not transpile dynamic import() when module is CommonJS #43329

Closed

5 tasks

sandersn reviewed Jun 22, 2021

View reviewed changes

andrewbranch requested changes Jun 22, 2021

View reviewed changes

just-boris mentioned this pull request Jun 22, 2021

Support for NodeJS 12.7+ package exports #33079

Closed

panva mentioned this pull request Jun 23, 2021

Module not found: Can't resolve 'jose/jwt/sign' panva/jose#193

Closed

renke mentioned this pull request Oct 13, 2021

Auto imports not working for modules exported via exports in package.json #46339

Closed

pwhissell mentioned this pull request Oct 15, 2021

Compiled JavaScript import is missing file extension #40878

Closed

mjbvz mentioned this pull request Oct 20, 2021

Explore enabling ESM based extensions microsoft/vscode#135450

Closed

DanielRosenwasser mentioned this pull request Oct 20, 2021

Concerns with TypeScript 4.5's Node 12+ ESM Support #46452

Closed

djfm mentioned this pull request Oct 24, 2021

Weird crash of Wayland when using "yab" command (but not dist/bin.js) djfm/YAB#1

Open

ctjlewis mentioned this pull request Oct 27, 2021

Lack of ESM entry-points prevents correct default import resolution vercel/next.js#30402

Closed

tylersayshi mentioned this pull request Nov 5, 2021

refactor: started to move to typescript josdejong/svelte-jsoneditor#21

Closed

andrewbranch mentioned this pull request Nov 10, 2021

--module nodenext self-name references don't work with an outDir from clean build #46762

Closed

chrisui mentioned this pull request Nov 24, 2021

(jest) Add export map entry DefinitelyTyped/DefinitelyTyped#57235

Merged

dudckd6744 mentioned this pull request Dec 18, 2021

tsc - node12 module 추가 dudckd6744/Study_calender#11

Open

orta mentioned this pull request Aug 9, 2022

Fix module resolution config option (+mention inline type on imports) microsoft/TypeScript-Website#2478

Merged

dsherret mentioned this pull request Sep 26, 2022

fix: correct exports in package.json denoland/dnt#221

Merged

cseas mentioned this pull request Jan 7, 2023

fix: package exports and ESM support hazel-ui/hazel-ui#167

Merged

2 tasks

TylerLeonhardt mentioned this pull request Jan 19, 2023

Don't bundle @vscode/l10n to save space microsoft/vscode-l10n#88

Open

rajsite added a commit to ni/nimble that referenced this pull request Jan 22, 2024

Export the types with the legacy types field

1839f04

Even though the TS docs and following comment say it's just a fallback :/ microsoft/TypeScript#44501 (comment)

	// If `target` refers to a shorthand module symbol, the name we're trying to pull out isn;t recoverable from the target symbol
	// If `target` refers to a shorthand module symbol, the name we're trying to pull out isn't recoverable from the target symbol

	* @param packageJsonInfoCache (Optional) A cache for package file lookups - it's best to have a cache when this function is called often
	* @param [packageJsonInfoCache] A cache for package file lookups - it's best to have a cache when this function is called often

Initial support for module: node12 #44501

Initial support for module: node12 #44501

Conversation

weswigham commented Jun 8, 2021 • edited Loading

weswigham commented Jun 8, 2021

typescript-bot commented Jun 8, 2021 • edited Loading

typescript-bot commented Jun 8, 2021 • edited Loading

weswigham commented Jun 14, 2021

typescript-bot commented Jun 14, 2021 • edited Loading

weswigham commented Jun 14, 2021

typescript-bot commented Jun 14, 2021 • edited Loading

typescript-bot commented Jun 14, 2021 • edited Loading

weswigham commented Jun 14, 2021

typescript-bot commented Jun 14, 2021 • edited Loading

andrewbranch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandersn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewbranch left a comment

Choose a reason for hiding this comment

weswigham commented Jun 23, 2021

andrewbranch commented Oct 13, 2021

benjie commented Nov 10, 2021 • edited Loading

andrewbranch commented Nov 10, 2021

benjie commented Nov 10, 2021

arpowers commented Nov 26, 2021

loynoir commented Dec 6, 2021 • edited Loading

nayeemrmn commented Aug 6, 2022

weswigham commented Aug 6, 2022 • edited Loading

nayeemrmn commented Aug 6, 2022 • edited Loading

weswigham commented Aug 7, 2022

weswigham commented Aug 7, 2022 • edited Loading

nayeemrmn commented Aug 7, 2022

lgarron commented Aug 7, 2022

weswigham commented Aug 8, 2022

thw0rted commented Aug 8, 2022 • edited Loading

weswigham commented Jun 8, 2021 •

edited

Loading

typescript-bot commented Jun 8, 2021 •

edited

Loading

typescript-bot commented Jun 8, 2021 •

edited

Loading

typescript-bot commented Jun 14, 2021 •

edited

Loading

typescript-bot commented Jun 14, 2021 •

edited

Loading

typescript-bot commented Jun 14, 2021 •

edited

Loading

typescript-bot commented Jun 14, 2021 •

edited

Loading

benjie commented Nov 10, 2021 •

edited

Loading

loynoir commented Dec 6, 2021 •

edited

Loading

weswigham commented Aug 6, 2022 •

edited

Loading

nayeemrmn commented Aug 6, 2022 •

edited

Loading

weswigham commented Aug 7, 2022 •

edited

Loading

thw0rted commented Aug 8, 2022 •

edited

Loading