-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Core: Migrate from qs
to picoquery
#28315
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 26659e4. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 1 targetSent with 💌 from NxCloud. |
Moves the `manager-api`, `preview-api` and `ui/amanger` to use `picoquery` instead of `qs` - a much smaller and faster alternative. Note that we still have `qs` in our overall monorepo tree, but that can be tackled in a follow-up PR.
Looks like there are a few extra qs references that are causing linting to fail! |
whoops my mistake! i forgot to run looks like you got it building though. let me know if you need any changes or help |
I swapped one of them over, but didn't go the extra distance to do the other two, which are a little more involved 🙈 |
no worries, its probably the one i left out on purpose happy to tackle that in its own PR as long as the rest of the packages build ok sure means we temporarily have both in the dependency tree but its small enough we'll be ok i think, and i can probably sort it fairly soon |
Uses the `foo.bar[0]` syntax picoquery provides, rather than dot-syntax (`foo.bar.0`).
note there's still one usage left i need to tackle i have failing tests locally for it but will get to it at some point 👍 |
Moves the preview api to use picoquery. Note that tests will not pass yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to move from qs to picoquery, but only if it involves no functional changes. Unfortunately, it seems picoquery urlencodes args, which aren't currently encoded. This would be a breaking change and make the URLs look really ugly, so I'm opposed to changing that behavior.
code/lib/router/src/utils.ts
Outdated
export const queryFromLocation = (location: Partial<Location>) => | ||
queryFromString(location.search ? location.search.slice(1) : ''); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export const queryFromLocation = (location: Partial<Location>) => | |
queryFromString(location.search ? location.search.slice(1) : ''); | |
export const queryFromLocation = (location: Partial<Location>) => | |
queryFromString(location.search.slice(1)); |
|
||
export const stringifyQueryParams = (queryParams: Record<string, string>) => | ||
qs.stringify(queryParams, { addQueryPrefix: true, encode: false }).replace(/^\?/, '&'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need some unit tests to verify stringifyQueryParams
doesn't change between the two implementations.
this is true, however it is doing the right thing here while qs/storybook hasn't been the URI spec defines it this way, and is why so we're blocked here i guess. i understand the URLs looked nicer, but they're non-standard and its unlikely pq will ever support that (since it is trying to conform to the standard and be interchangeable with the dependency tree & package size reduction is what i've been chipping away at for months now. it'd be a shame to back off from that for nice looking URLs, especially given alternatively, we could have code inside storybook which literally does |
That works for me. It's hacky but at least it's consistent. If being noncompliant turns out to be an issue then we can always change it in a major version release (in which case I'd opt for a different/custom array encoding to avoid |
no worries, that works for me too we already do some transforms on the parsed and stringified queries so it won't be much to add to that |
Decodes certain chars we want to keep in our URIs (e.g. `[`).
we have some failures ill have to get to at some point another day 👍 basically what to do about invalid keys since pq will deal with them differently than qs did (for perf mostly) e.g. |
const args = parseArgsParam('key:!date(2001-02-03T04:05:06.789+09:00)'); | ||
const args = parseArgsParam('key:!date(2001-02-03T04:05:06.789%2B09:00)'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are all these updated tests not indications that this is backwards incompatible, and we should delay merging this until the next major version @JReinhold ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't agree with this updated format to begin with. +
is valid in a URL. Moreover, this is fully client-side URL parsing so we don't even have to adhere to the specs necessarily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this instance is what I'm commenting on here:
https://github.com/storybookjs/storybook/pull/28315/files#r1763000236
as for the other tests, it looks to me that they were testing that invalid paths were still "working", and it's fine to me that they don't work the same. I don't see how they could possibly be constructed by us, so the user must have manually written an invalid query param, and I don't feel the need to support that at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
elsewhere, we translate spaces to +
so maybe I also missed a place where we need to do the same
…eArgsParam.test.ts
…detect uppercase color prefixes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
Great work landing this 🙌 If you run into anything in the pre release, let me know and I'll try help out |
Thanks for the help @43081j ❤️ |
Moves the
manager-api
,preview-api
andui/manager
to usepicoquery
instead ofqs
- a much smaller and faster alternative.Note that we still have
qs
in our overall monorepo tree, but that can be tackled in a follow-up PR.Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
Manual testing
Existing stories and tests should continue to function correctly.
Documentation
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal
,ci:merged
orci:daily
GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli/src/sandbox-templates.ts
Make sure this PR contains one of the labels below:
Available labels
bug
: Internal changes that fixes incorrect behavior.maintenance
: User-facing maintenance tasks.dependencies
: Upgrading (sometimes downgrading) dependencies.build
: Internal-facing build tooling & test updates. Will not show up in release changelog.cleanup
: Minor cleanup style change. Will not show up in release changelog.documentation
: Documentation only changes. Will not show up in release changelog.feature request
: Introducing a new feature.BREAKING CHANGE
: Changes that break compatibility in some way with current major version.other
: Changes that don't fit in the above categories.