Merge branch 'dev' of github.com:remix-run/remix into chance/future-meta

.changeset/happy-flies-own.md

@@ -0,0 +1,6 @@
+---
+"remix": patch
+"@remix-run/eslint-config": patch
+---
+
+Replace references to the old `migrate` command with the new `codemod` command

.changeset/khaki-meals-prove.md

@@ -0,0 +1,12 @@
+---
+"@remix-run/architect": minor
+"@remix-run/cloudflare": minor
+"@remix-run/node": minor
+"@remix-run/react": minor
+"@remix-run/server-runtime": minor
+---
+
+Importing functions and types from the `remix` package is deprecated, and all
+exported modules will be removed in the next major release. For more details,
+[see the release notes for 1.4.0](https://github.com/remix-run/remix/releases/tag/v1.4.0)
+where these changes were first announced.

.changeset/moody-cats-relax.md

@@ -0,0 +1,9 @@
+---
+"remix": patch
+"@remix-run/node": patch
+---
+
+chore: update @remix-run/web-fetch to 4.3.2
+
+- fix: Memory leak caused by unregistered listeners. Solution was copied from a node-fetch pr.
+- fix: Add support for custom "credentials" value. Nothing is done with them at the moment but they pass through for the consumer of the request to access if needed.

.changeset/neat-months-run.md

@@ -0,0 +1,8 @@
+---
+"remix": patch
+"@remix-run/dev": patch
+---
+
+bump esbuild to fix an issue with spreading props followed by a key as well as a `jsx name collision edge case` when using packages with the name `react` in them, like `@remix-run/react`.
+
+it also utilizies esbuild's native yarn pnp compatibility instead of using `@yarnpkg/esbuild-plugin-pnp`

.github/workflows/nightly.yml

@@ -60,7 +60,7 @@ jobs:
 
             DATE=$(date '+%Y%m%d')
             NEXT_VERSION=0.0.0-nightly-${SHORT_SHA}-${DATE}
-            echo ::set-output name=NEXT_VERSION::${NEXT_VERSION}
+            echo "NEXT_VERSION=${NEXT_VERSION}" >> $GITHUB_OUTPUT
 
             git checkout -b nightly/${NEXT_VERSION}
 

.github/workflows/no-response.yml

@@ -1,8 +1,6 @@
 name: 🥺 No Response
 
 on:
-  issue_comment:
-    types: [created]
   schedule:
     # Schedule for five minutes after the hour, every hour
     - cron: "5 * * * *"
@@ -12,14 +10,14 @@ permissions:
   pull-requests: write
 
 jobs:
-  noResponse:
+  stale:
     if: github.repository == 'remix-run/remix'
     runs-on: ubuntu-latest
-
     steps:
       - name: 🥺 Handle Ghosting
-        uses: actions/stale@v5
+        uses: actions/stale@v6
         with:
+          days-before-close: 10
           close-issue-message: >
             This issue has been automatically closed because we haven't received a
             response from the original author 🙈. This automation helps keep the issue
@@ -30,8 +28,7 @@ jobs:
             response from the original author 🙈. This automation helps keep the issue
             tracker clean from PRs that are unactionable. Please reach out if you
             have more information for us! 🙂
-          days-before-close: 10
           # don't automatically mark issues/PRs as stale
           days-before-stale: -1
-          any-of-labels: needs-response
-          labels-to-remove-when-unstale: needs-response
+          stale-issue-label: needs-response
+          stale-pr-label: needs-response

contributors.yml

@@ -11,6 +11,7 @@
 - aiji42
 - airjp73
 - airondumael
+- aissa-bouguern
 - Alarid
 - alex-ketch
 - alextes
@@ -249,12 +250,14 @@
 - levippaul
 - LewisArdern
 - lifeiscontent
+- lili21
 - lionotm
 - liranm
 - lpsinger
 - lswest
 - lucasdibz
 - luispagarcia
+- luisrivas
 - luistak
 - luistorres
 - luk-str
@@ -285,6 +288,7 @@
 - mattmazzola
 - mattstobbs
 - maxprilutskiy
+- maxschwarzmueller
 - mbarto
 - mcansh
 - mdoury
@@ -429,6 +433,7 @@
 - vlindhol
 - vmosyaykin
 - vorcigernix
+- wangbinyq
 - weavdale
 - willhack
 - willin
@@ -445,4 +450,3 @@
 - zachdtaylor
 - zainfathoni
 - zhe
-- maxschwarzmueller

decisions/0006-linear-workflow.md

@@ -0,0 +1,86 @@
+# Linear Workflow
+
+Date: 2022-09-06
+
+Status: accepted
+
+## Context
+
+The Remix development team uses Linear internally to manage and prioritize ongoing development of Remix and React-Router. In order to keep this process flowing smoothly, we document here the set of established workflows within Linear, so developers have a documented process to refer to if questions should arise.
+
+## Linear Terms
+
+This document will use many of the following Linear terms:
+
+- **Issue** - A ticket/task in the Linear system that describes a unit of work to be completed
+- **Cycle** - A group of issues aimed to be completed within a given 1-week period (similar to a "sprint" in other Agile workflows)
+- **Project** - A group of issues that comprise a larger scope of work (for example, a new feature)
+  - Projects will almost always span multiple Cycles.
+- **Status** - The state of a given Issue (Todo, In Progress, Done, etc.)
+- **Assignee** - The person the Issue is currently assigned to - this indicates who is expected to take the next action to move the Issue forward
+- **Label** - Linear Issues can be assigned one or more Labels for filtering/searching
+
+## Decision
+
+### Status Definitions
+
+The Linear workflow is governed by the **Status** field, which has the following options:
+
+- **Triage** - Issue is not yet reviewed and we have no idea if we'll actually do this work
+- **Backlog** - Issue has been accepted as something we would like to do, but is not currently planned
+- **Todo** - Issue has been planned for a given Cycle of work
+- **In Progress** - Issue is actively being worked on in the active Cycle
+- **In Review** - Issue is completed and in a PR receiving feedback
+- **Needs Feedback** - Developer is blocked and needs feedback from someone else before they can be unblocked
+- **Done** - Issue has been completed and merged (note this does not mean released)
+- **Canceled** - Issue is not going to be done
+
+### General Workflow
+
+Generally, the Linear workflow is as follows:
+
+```mermaid
+graph TD
+    A(Github/Discord/???) -->|intake| Triage
+    Triage -->|accepted| Backlog
+    Triage -->|rejected| Canceled
+    Backlog -->|planned| Todo
+    Todo -->|picked up| InProgress(In Progress)
+    InProgress -->|PR| InReview(In Review)
+    InProgress -->|stopped| Todo
+    InProgress -->|blocked| NeedsFeedback(Needs Feedback)
+    NeedsFeedback -->|unblocked| InProgress
+    InReview -->|larger changes| InProgress
+    InReview -->|small comments| InReview
+    InReview -->|merged| Done
+```
+
+In more detail, the following is the _standard_ flow of a Linear Issue:
+
+1. When an idea or bug fix is identified through a Github Discussion/Issue/PR, we will create a Linear Issue in the **Triage** Status to track the task
+   1. This should contain an appropriate title and a link to the original idea in github
+2. The issue will be reviewed by the team (with final approval on larger changes and new APIs coming from Michael/Ryan)
+   1. If we want to move forward with the Issue, it gets moved to the **Backlog** Status
+   2. If we do not want to move forward with the Issue, it get moved to the **Canceled** Status, with appropriate reasoning provided in the Linear Issue and the original Github source.
+3. Periodically, Issues in the **Backlog** Status will be planned into a given cycle, and moved to the **Todo** Status
+4. During the active Cycle, a developer will pick up a ticket to start work and will move it into the **In Progress** Status
+5. Once the work is completed and a PR is opened, the developer will move the Issue to the **In Review** Status and assign it to the person who should perform the review
+6. If feedback is needed, comments can be left on the PR and the ticket can switch between assignees while remaining in the **In Review** status
+   1. Only for larger-scale changes should an Issue be moved back to **In Progress**
+7. Once merged, the Issue can be moved to the **Done** Status
+
+As always, this is not an absolute workflow and there will be exceptions. Here's a few examples:
+
+- If an issue opened on Github is a small bugfix, it can bypass the **Triage** status and go straight to the **Backlog** status. Or potentially even right into **Todo** if a developer has capacity to pick up the bug in the active (or upcoming) Cycle.
+- If a developer is blocked on moving forward with an Issue, it can be moved to the **Needs Feedback** Status and assigned to the person who can unblock the Issue
+- Sometimes an issue will be abandoned well after it was accepted and moved into the **Backlog** Status, and in these cases an Issue can always be assigned to **Canceled**
+
+### Ongoing Processes
+
+- Any idea/bug coming in via Github or Discord (or elsewhere) can be put into an Issue in the **Triage** status for review
+- Michael and Ryan should review the **Triage** Issues on a regular (weekly?) basis and move tickets to **Backlog** or **Canceled**
+  - If tickets are accepted, they should be given appropriate Labels and/or Projects
+  - If tickets are rejected, we should provide the rationale in the Linear ticket and on the original source (i.e., github)
+- Michael/Ryan (and team?) will decide what to work on in a given Cycle and move tickets from **Backlog** to **Todo** and assign a proper Cycle
+- All team members should review any tickets assigned to them on a regular (daily?) basis and provide reviews/feedback as needed to keep tickets moving along
+- All team members should work from their **Todo** queue during active Cycles

docs/pages/community.md

@@ -31,6 +31,8 @@ Here's a list of courses (in no particular order) you can take to help learn Rem
 - [Learn Remix by Building a Social Media Platform with TypeScript and Prisma][learn-remix-by-building-a-social-media-platform-with-type-script-and-prisma] by [Ian Jones][ian-jones] on [Egghead.io][egghead-io]
 - [Remix for Everyone][remix-for-everyone] by [Scott Tolinski][scott-tolinski] on [Level Up Tutorials][level-up-tutorials]
 - [Realtime Remix with Supabase][realtime-remix-with-supabase] by [Jon Meyers][jon-meyers] on [Level Up Tutorials][level-up-tutorials]
+- [Remix Fundamentals][remix-fundamentals] by [Kent C. Dodds][kent-c-dodds] on [Frontendmasters][frontend-masters]
+- [Advanced Remix][advanced-remix] by [Kent C. Dodds][kent-c-dodds] on [Frontendmasters][frontend-masters]
 
 If you need to learn React first, [this free egghead course][this-free-egghead-course] by Kent C. Dodds has everything you need.
 
@@ -89,3 +91,6 @@ There are Remix Meetups all over the world with thousands of members. Some onlin
 [remix-conf]: ../../../../conf
 [the-remix-meetup-page]: https://rmx.as/meetup
 [remix-guide]: https://remix.guide
+[frontend-masters]: https://frontendmasters.com
+[remix-fundamentals]: https://frontendmasters.com/courses/remix/
+[advanced-remix]: https://frontendmasters.com/courses/advanced-remix/