Releases: happykit/flags
@happykit/[email protected]
Minor Changes
-
79d13e9: allow disabling visitor key cookie
You can now configure or disable the visitor key cookie
@happykit/flagssets by default. You can pass aserializeVisitorKeyCookiefunction to the options when callingcreateUseFlagsandcreateGetFlags.
@happykit/[email protected]
Minor Changes
-
e473304: add Next.js App Router support
HappyKit has a feature called
visitorKey, you can learn more about it here. If you want to use this feature with App Router you need to set the cookie from middleware using theensureVisitorKeyCookiefrom@happykit/flags/edge. See theexample/middleware.tsfile in this repository for an example of how to do this. This is necessary as App Router pages can not set any cookies when they render, so we have to fall back to setting the cookie from middleware instead. If you do not need thevisitorKeyfor your custom evaluation rules or rollouts then you do not need to set the cookie from middleware.
@happykit/[email protected]
Patch Changes
- 21a540c: add cache: no-store to all fetch requests
@happykit/[email protected]
Patch Changes
- c53e69a: ensure getEdgeFlags is compatible with Next.js 13.4
v3.0.0
Major Changes
-
1822587: BREAKING CHANGE: Configuration overhaul
What
This release changes HappyKit's configuration approach.
Previously you had to create a
flags.config.jsfile and import it into yourpages/_app.jsand into every middleware that wanted to use feature flags. If you were using your ownAppFlagstype, you also had to pass this type every time you invokedgetFlags(),useFlags()orgetEdgeFlags(). And the configuration options for client-, server- and edge were mixed together into a singleflags.config.jsfile.Why
This release replaces the existing configuration approach with a new one. This new approach configuration prepares happykit for upcoming features.
How
1. Add
flagsfolderFollow the updated Setup instructions to create the
flagsfolder in your own application, and fill it with.After this step, you should have
./flags/config.tswhich exports a configuration./flags/client.tswhich exports auseFlagsfunction./flags/server.tswhich exports agetFlagsfunction./flags/edge.tswhich exports agetEdgeFlagsfunction
2. Set up absolute imports
Enable Absolute Imports as described here.
3. Adapt your imports
Then change the application code in your
pages/folder to use these functions from yourflags/folder instead of from@happykit/flags:- import { useFlags } from "@happykit/flags/client" + import { useFlags } from "flags/client"
- import { getFlags } from "@happykit/flags/server" + import { getFlags } from "flags/server"
- import { getEdgeFlags } from "@happykit/flags/edge" + import { getEdgeFlags } from "flags/edge"
_Note that because of the absolute imports we configured in step 2, all imports from
"flags/"will use the local flags folder you created in step 1.*4. Delete your old setup
We can now delete the old setup since we no longer need it
- delete
flags.config.js - remove the
flags.configimport from yourpages/_appfile- you might be able to delete the
pages/_appfile if it's not doing anything else anymore
- you might be able to delete the
- remove the import of
flags.configfrom your middleware
v2.0.7
v2.0.6
- config did not update when used as esm bundle, introduced internal
getConfig()to fix it #24
Breaking change
If you were doing import { config } from "@happykit/flags/config", you now need to import { getConfig } from "@happykit/flags/config". I believe most people are not importing config into their app.
This was a breaking I only realized after publishing as v2.0.6, so the sem ver does not reflect the breaking change. I apologize if this broke your build.
v2.0.5-perf.0 (Latency Metrics Release)
This is a special once-off release which is equal to v2.0.5, except for additional latency metrics reporting.