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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: use package ranges instead of specifying versions #292

Closed
wants to merge 1 commit into from

Commits on Jan 6, 2023

  1. fix: use package ranges instead of specifying versions

    This undos the exact version change pushed in JosteinKringlen#282
    
    - remix-auth is moved to `peerDependencies` as the documentation for
      remix-auth-spotify specifies that it should be manually installed.
    - remix-auth is added to `devDependencies` for any tests that rely on
      remix have access to them.
    - remix-auth-oauth2 is made into a package range that will support all
      1.x.x releases >= 1.5.0.
    
    This change was made because installing as specifed in the documentation
    lead to multiple versions of remix being installed which does not work
    with any typescript type overloading that you might do.
    
    remix-run/remix#1876
    
    For example, I have an existing remix app using [email protected] with the
    following in my remix.env.d.ts:
    
    ```typescript
    // in remix.env.d.ts
    import '@remix-run/server-runtime'
    
    declare module '@remix-run/server-runtime' {
      interface AppLoadContext {
        requestId: string
      }
    }
    ```
    
    This allows me to access the `requestId` in a `loader` like so:
    
    ```typescript
    import { LoaderArgs  } from '@remix-run/node'
    
    export async function loader({ context }) {
      foobar(context.requestId)
    }
    ```
    
    Installing remix-auth-spotify as specified in the docs caused
    [email protected] to be installed alongside 1.7.4. This caused the type
    overriding in Typescript to not work at all and make `context.requestId`
    become unknown. This was resolved by bumping up remix to 1.9.0 in my
    package.json. By using package ranges, downstream consumers of this
    package are able to define the versions of remix.
    
    Question: If accepted, would it make sense to also have
    remix-auth-oauth2 moved to `peerDependencies`? I could envision an
    authentication a situation where the upstream consumer of this package
    has Spotify auth AND a custom OAuth2 setup. I don't have a super strong
    stance, though.
    eligundry committed Jan 6, 2023
    Configuration menu
    Copy the full SHA
    794c099 View commit details
    Browse the repository at this point in the history