Nullable fields which are not marked as null
NyCodeGHG opened this issue · 6 comments
I've found some nullable fields which are not marked as null, I've tried to make a PR but I found the "non monorepo" monorepo style really confusing. I couldn't get it to use my changes. I think something like pnpm workspaces would work better here?
Nullable Fields:
country_at
in Player Infoplayer_locale
in Player InforoundDamage
in Match DetailssessionPlaytimeMinutes
in Match DetailsabilityCasts
in Match DetailsplayerEconomies
in Match DetailsplayerScores
in Match Details
Thanks for the info 👍
Right now, I'm just using the types library version on npm for building the web docs instead of the local version.
If you have the local version built, it should be as easy as uninstalling the version from npm and running an npm install with the path to the local version.
Honestly, I think I just did this to make CI simpler, it could go either way.
Does the pnpm workspace make handling things simpler than a local npm package? I'm not sure I understand.
Oh also I don't even test the web version of things locally lmao. I just sorta trust that it works and fix it if it breaks in "prod" (hasn't yet 🤞).
Does the pnpm workspace make handling things simpler than a local npm package? I'm not sure I understand.
pnpm workspaces are made to solve this problem. Yarn and npm offer similar things but i've found the pnpm version the easiest to work with.
You are able to have multiple npm projects in a single repo and can use local changes without needing to publish them. I can make a PR if you want to try that out.
Does a npm installation from the filesystem do the same thing or have any downsides compared to the pnpm workspace? And does the pnpm workspace have a "vanilla" downgrade like how you can still use npm in pnpm repos?
you must use pnpm in a pnpm workspace to function correctly. But you can install pnpm easily on Node 16+ with corepack enable
.
By default pnpm is a bit different, it symlinks to save storage and only symlinks direct dependencies to avoid using transitive dependencies, but that can be changed with a flag.
Ah I see. In that case, I think it would be best to stick with the npm setup for now, but I appreciate the info, thank you 👍