fix(remix-server-runtime): make DataFunctionArgs a type alias

[MichaelDeBoey]

Follow-up of @brophdawg11's #7360

I don't think we want people to override DataFunctionArgs as they can already override AppLoadContext

[changeset-bot]

🦋 Changeset detected

Latest commit: 3ca6521

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@remix-run/dev	Patch
create-remix	Patch
remix	Patch
@remix-run/architect	Patch
@remix-run/cloudflare	Patch
@remix-run/cloudflare-pages	Patch
@remix-run/cloudflare-workers	Patch
@remix-run/css-bundle	Patch
@remix-run/deno	Patch
@remix-run/eslint-config	Patch
@remix-run/express	Patch
@remix-run/node	Patch
@remix-run/react	Patch
@remix-run/serve	Patch
@remix-run/server-runtime	Patch
@remix-run/testing	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brophdawg11]

🤣 I can't keep up with this type versus interface stuff - we export a ton of both 🤷

Wanna add a changeset so it triggers a prerelease? I'll lump it in with #7361 tomorrow

[MichaelDeBoey]

@brophdawg11 Basically we should almost always use type aliases unless we want to support interface augmentation (which is almost never the case)

[brophdawg11]

Would you want to work with @pcattori to get together some sort of decision doc or guidelines around this stuff? From a quick count, I counted ~20 or so interfaces in the 45 exports from @remix-run/server-runtime so we don't have any sort of rule at the moment. Is there any way this stuff could be enforced via a linter? Otherwise we'll keep drifting off track over time 😕

[MichaelDeBoey]

@brophdawg11 I'll create a PR that makes all of them a type alias + enable linting rules that enforce this 👍

RR should only do that as part of v7 as it would technically be a breaking change to make it a type alias

[brophdawg11]

We can merge this since it aligns better with the LoaderFunctionArgs/ActionFunctionArgs types, but for the rest of the associated PRs I'm going to close them out for now since we need to first define/document a stance as a team before we go mass-updating the current code. And then we need to figure out if we want to churn the TS API with V3_ types in v2 or just document it as a find/replace when v3 releases.

[github-actions]

🤖 Hello there,

We just published version 2.0.0-pre.10 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version v0.0.0-nightly-3646f91-20230914 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 2.0.0 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!