chore(deps): use exact versions #282
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
🎉 This PR is included in version 1.2.7 🎉 The release is available on: Your semantic-release bot 📦🚀 |
eligundry
added a commit
to eligundry/remix-auth-spotify
that referenced
this pull request
Jan 6, 2023
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 remix@1.7.4 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: ``` import { LoaderArgs } from '@remix-run/node' export async function loader({ context }) { foobar(context.requestId) } ``` Installing remix-auth-spotify as specified in the docs caused remix@1.9.0 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
added a commit
to eligundry/remix-auth-spotify
that referenced
this pull request
Jan 6, 2023
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 remix@1.7.4 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 remix@1.9.0 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
added a commit
to eligundry/remix-auth-spotify
that referenced
this pull request
Jan 6, 2023
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 remix@1.7.4 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 remix@1.9.0 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.