Skip to content

[node] events: refactor module structure#70635

Closed
Renegade334 wants to merge 3 commits intoDefinitelyTyped:masterfrom
Renegade334:node-events-namespace
Closed

[node] events: refactor module structure#70635
Renegade334 wants to merge 3 commits intoDefinitelyTyped:masterfrom
Renegade334:node-events-namespace

Conversation

@Renegade334
Copy link
Contributor

@Renegade334 Renegade334 commented Sep 22, 2024

The structure of the events module in @types/node hasn't really changed since TS3, and is an unholy assortment of definition paradigms and circuitous import-export behaviour (the module imports itself, via a different module, in order to re-declare itself as its own namespace property...) Additionally, the top-level functions/variables in the events module are currently defined as static properties on the EventEmitter "class", which doesn't mirror how they're implemented or documented in Node, and which subjects them to unnecessary accessibility checks etc. by the compiler.

This changeset looks large, but it's only a small number of restructuring tasks:

  • Removes the circuitous self-imports, and defines a clean EventEmitter namespace containing all of the functions, variables and types that need exporting. This yields around a 10% reduction in instantiations for events.d.ts.
  • Exports some previously unexported types (options interfaces etc.)
  • Redefines the top-level variables/functions as namespace exports, rather than static elements on the EventEmitter pseudoclass. This doesn't change how those symbols are imported or referenced by the consumer, but does more accurately reflect the actual structure of the module. It also allows those functions to be overloaded by module augmentation definitions, which is not possible with class static methods.
  • Reorders everything to mirror the ordering of the Node API documentation, to make maintenance easier.

There should be no change in import behaviour: both CJS- and ESM-style imports will continue to work the same as before.

This also includes an additional change in v22, which is to move the EventEmitter class definitions from the NodeJS.EventEmitter interface to the EventEmitter class itself. NodeJS.EventEmitter was the global event emitter interface added to @types/node in v0, prior to the existence of the events module and the EventEmitter class, which hangs around now as a vestigial entity that simply doesn't need to exist any more. While this change is transparent to consumers of the EventEmitter class, and keeps the global interface unaltered, it lays the groundwork for removing NodeJS.EventEmitter entirely in the next major @types/node version.

@Renegade334 Renegade334 force-pushed the node-events-namespace branch 4 times, most recently from 9f6031b to fc74ffa Compare September 22, 2024 13:41
@Renegade334 Renegade334 marked this pull request as ready for review September 22, 2024 14:40
@typescript-bot
Copy link
Contributor

typescript-bot commented Sep 22, 2024

@Renegade334 Thank you for submitting this PR!

This is a live comment that I will keep updated.

1 package in this PR

Code Reviews

Because this is a widely-used package, a DT maintainer will need to review it before it can be merged.

You can test the changes of this PR in the Playground.

Status

  • ✅ No merge conflicts
  • ❌ Continuous integration tests have failed
  • 🕐 Most recent commit is approved by a DT maintainer

Once every item on this list is checked, I'll ask you for permission to merge and publish the changes.

Inactive

This PR has been inactive for 10 days.


Diagnostic Information: What the bot saw about this PR
{
  "type": "info",
  "now": "-",
  "pr_number": 70635,
  "author": "Renegade334",
  "headCommitOid": "a293e4fa6171cd41843c31cc39c2b064017fc997",
  "mergeBaseOid": "2fc2fb9ba5cc0b68fe14c9fd9e21fadbd9a781a6",
  "lastPushDate": "2024-09-22T11:53:23.000Z",
  "lastActivityDate": "2024-09-24T22:06:15.000Z",
  "hasMergeConflict": false,
  "isFirstContribution": false,
  "tooManyFiles": false,
  "hugeChange": false,
  "popularityLevel": "Critical",
  "pkgInfo": [
    {
      "name": "node",
      "kind": "edit",
      "files": [
        {
          "path": "types/node/events.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/node/test/events.ts",
          "kind": "test"
        },
        {
          "path": "types/node/v18/events.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/node/v18/test/events.ts",
          "kind": "test"
        },
        {
          "path": "types/node/v20/events.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/node/v20/test/events.ts",
          "kind": "test"
        }
      ],
      "owners": [
        "Microsoft",
        "jkomyno",
        "alvis",
        "r3nya",
        "btoueg",
        "smac89",
        "touffy",
        "DeividasBakanas",
        "eyqs",
        "Hannes-Magnusson-CK",
        "hoo29",
        "kjin",
        "ajafff",
        "islishude",
        "mwiktorczyk",
        "mohsen1",
        "galkin",
        "parambirs",
        "eps1lon",
        "ThomasdenH",
        "WilcoBakker",
        "wwwy3y3",
        "samuela",
        "kuehlein",
        "bhongy",
        "chyzwar",
        "trivikr",
        "yoursunny",
        "qwelias",
        "ExE-Boss",
        "peterblazejewicz",
        "addaleax",
        "victorperin",
        "ZYSzys",
        "NodeJS",
        "LinusU",
        "wafuwafu13",
        "mcollina",
        "Semigradsky"
      ],
      "addedOwners": [],
      "deletedOwners": [],
      "popularityLevel": "Critical"
    }
  ],
  "reviews": [],
  "mainBotCommentID": 2366820581,
  "ciResult": "fail",
  "ciUrl": "https://github.com/DefinitelyTyped/DefinitelyTyped/commit/a293e4fa6171cd41843c31cc39c2b064017fc997/checks?check_suite_id=29238045633"
}

@typescript-bot
Copy link
Contributor

@jakebailey
Copy link
Member

Are you skipping the refactor in the v16 dir intentionally? (I know it's technically EOL, though we're fiddling with things for TS changes and v16 still gets a good 800k weekly downloads.)

Is it accurate to say that this should go in before #69997 (if we're taking that)?

@Renegade334
Copy link
Contributor Author

Are you skipping the refactor in the v16 dir intentionally? (I know it's technically EOL, though we're fiddling with things for TS changes and v16 still gets a good 800k weekly downloads.)

I was, but that's not to say that it can't be included.

Is it accurate to say that this should go in before #69997 (if we're taking that)?

The two don't really overlap in their scope, although if the problematic efforts to genericise the top-level once() and on() functions aren't included in that PR, then namespace-ifying those functions does offer users an alternative approach to adding event map behaviour to those functions by adding overload signatures.

@jakebailey
Copy link
Member

jakebailey commented Sep 24, 2024

Given we're still noodling on fixing iterator/buffer related things that are getting patched in v16, I think it would probably be worthwhile to apply this fix there too for the time being to keep everything consistent; hopefully we can drop that at some point.

Sorry to make more work :(

@ckohen
Copy link
Contributor

ckohen commented Sep 24, 2024

namespace-ifying those functions does offer users an alternative approach to adding event map behaviour to those functions by adding overload signatures

Worth noting this is exactly the reason that pr was open in the first place. reopening class definitions with a namespace (the only way to modify static members) was possible due to a ts bug, and fixing that broke this very desirable behavior. I still believe having native overloads is extremely important, but this lessens the need.

I think realistically these want to land around the same time if possible, the change in the EventMap type from any[] to unknown[] in my PR (for better internal safety if we decided to use it not as a constraint) is non-breaking because it's not exported and has no change because it's only a constraint right now. Changing it after this lands (where it gets exported) is technically breaking.

@typescript-bot typescript-bot added the Has Merge Conflict This PR can't be merged because it has a merge conflict. The author needs to update it. label Sep 26, 2024
@typescript-bot
Copy link
Contributor

@Renegade334 Unfortunately, this pull request currently has a merge conflict 😥. Please update your PR branch to be up-to-date with respect to master. Have a nice day!

@Renegade334 Renegade334 force-pushed the node-events-namespace branch from 8c04086 to a293e4f Compare October 4, 2024 23:21
@typescript-bot typescript-bot added Unreviewed No one showed up to review this PR, so it'll be reviewed by a DT maintainer. and removed Has Merge Conflict This PR can't be merged because it has a merge conflict. The author needs to update it. labels Oct 4, 2024
@typescript-bot
Copy link
Contributor

@typescript-bot typescript-bot added The CI failed When GH Actions fails and removed Unreviewed No one showed up to review this PR, so it'll be reviewed by a DT maintainer. labels Oct 4, 2024
@typescript-bot
Copy link
Contributor

@Renegade334 The CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

Note: builds that are failing do not end up on the list of PRs for the DT maintainers to review.

@Renegade334 Renegade334 marked this pull request as draft October 4, 2024 23:49
@Renegade334
Copy link
Contributor Author

Blocking on #69997.

@ckohen
Copy link
Contributor

ckohen commented Oct 5, 2024

I thought this would land first, which is why I hadn't rebased yet. I can work with either way.

@Renegade334
Copy link
Contributor Author

Think it'd be better to merge the event map changes first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants