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/flags
sets by default. You can pass aserializeVisitorKeyCookie
function to the options when callingcreateUseFlags
andcreateGetFlags
.
@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 theensureVisitorKeyCookie
from@happykit/flags/edge
. See theexample/middleware.ts
file 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 thevisitorKey
for 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.js
file and import it into yourpages/_app.js
and into every middleware that wanted to use feature flags. If you were using your ownAppFlags
type, 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.js
file.Why
This release replaces the existing configuration approach with a new one. This new approach configuration prepares happykit for upcoming features.
How
1. Add
flags
folderFollow the updated Setup instructions to create the
flags
folder in your own application, and fill it with.After this step, you should have
./flags/config.ts
which exports a configuration./flags/client.ts
which exports auseFlags
function./flags/server.ts
which exports agetFlags
function./flags/edge.ts
which exports agetEdgeFlags
function
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.config
import from yourpages/_app
file- you might be able to delete the
pages/_app
file if it's not doing anything else anymore
- you might be able to delete the
- remove the import of
flags.config
from 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.