Skip to content

refactor: types from 'any' to 'unknown' #3062

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.

Sign up for GitHub

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

Closed
wants to merge 5 commits into from
Closed

refactor: types from 'any' to 'unknown' #3062

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
44fff3b
Change StateTree type from 'any' to 'unknown'
kazbekaskarov Nov 6, 2025
2d4bf9d
Refactor types from 'any' to 'unknown' in hmr.ts
kazbekaskarov Nov 6, 2025
c1bf1c6
chore: bump pinia version to 3.0.5
kazbekaskarov Nov 6, 2025
3b07168
chore: bump @pinia/nuxt version to 0.11.4
kazbekaskarov Nov 6, 2025
317cfd1
chore: bump @pinia/testing version to 1.0.4
kazbekaskarov Nov 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion packages/nuxt/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "@pinia/nuxt",
"version": "0.11.3",
"version": "0.11.4",
"description": "Nuxt Module for pinia",
"keywords": [
"pinia",
Expand Down
2 changes: 1 addition & 1 deletion packages/pinia/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "pinia",
"version": "3.0.4",
"version": "3.0.5",
"description": "Intuitive, type safe and flexible Store for Vue",
"type": "module",
"main": "index.cjs",
Expand Down
12 changes: 6 additions & 6 deletions packages/pinia/src/hmr.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ import {
* @param fn - object to test
* @returns true if `fn` is a StoreDefinition
*/
export const isUseStore = (fn: any): fn is StoreDefinition => {
export const isUseStore = (fn: unknown): fn is StoreDefinition
return typeof fn === 'function' && typeof fn.$id === 'string'
}
Comment on lines +19 to 21
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify TypeScript compilation with property access on unknown.

While changing the parameter to unknown improves type safety, accessing fn.$id after only checking typeof fn === 'function' may cause a TypeScript error. TypeScript doesn't infer that functions can have custom properties without additional narrowing.

Run the following to verify compilation:

🏁 Script executed:

#!/bin/bash
# Check if the project builds successfully with these type changes
cd packages/pinia
npm run build 2>&1 | grep -A 5 -B 5 "error TS"

Length of output: 0

🏁 Script executed:

#!/bin/bash
# First, verify the file exists and show its content
echo "=== Checking hmr.ts content ==="
find . -name "hmr.ts" -type f | head -5

echo ""
echo "=== Full content of hmr.ts ==="
cat packages/pinia/src/hmr.ts || echo "File not found at expected path"

echo ""
echo "=== Checking tsconfig.json ==="
cat packages/pinia/tsconfig.json 2>/dev/null || echo "tsconfig.json not found"

echo ""
echo "=== Checking package.json build script ==="
grep -A 2 '"build"' packages/pinia/package.json || echo "Build script not found"

Length of output: 3884

🏁 Script executed:

#!/bin/bash
# First, verify the file exists and show its content
echo "=== Checking hmr.ts content ==="
find . -name "hmr.ts" -type f | head -5

echo ""
echo "=== Full content of hmr.ts ==="
cat packages/pinia/src/hmr.ts || echo "File not found at expected path"

echo ""
echo "=== Checking tsconfig.json ==="
cat packages/pinia/tsconfig.json 2>/dev/null || echo "tsconfig.json not found"

echo ""
echo "=== Checking package.json build script ==="
grep -A 2 '"build"' packages/pinia/package.json || echo "Build script not found"

Length of output: 3884

Fix syntax error: missing opening brace in isUseStore function signature.

The function at line 19 is missing the opening brace { after the type predicate. The line break splits the signature from the body:

export const isUseStore = (fn: unknown): fn is StoreDefinition {
  return typeof fn === 'function' && typeof fn.$id === 'string'
}

Additionally, accessing fn.$id on a narrowed Function type creates a type safety issue—functions don't have a $id property by default. Consider either casting to a more specific type or using optional chaining if runtime safety is intended.

🧰 Tools
🪛 Biome (2.1.2)

[error] 20-20: Line terminator not permitted before arrow.

(parse)

[error] 20-21: Expected a statement but instead found '}'.

Expected a statement here.

(parse)

🤖 Prompt for AI Agents 
In packages/pinia/src/hmr.ts around lines 19 to 21, the isUseStore function is
missing the opening brace after its type predicate and is unsafely accessing
fn.$id on a plain Function type; add the missing "{" to start the function body
and change the property access to a safe form (for example cast fn to any or a
narrower interface or use optional chaining) so the runtime check becomes
something like typeof (fn as any).$id === 'string' (or typeof (fn as { $id?:
unknown }).$id === 'string') to preserve type safety while fixing the syntax
error.


Expand All @@ -30,9 +30,9 @@ export const isUseStore = (fn: any): fn is StoreDefinition => {
* @returns - newState
*/
export function patchObject(
newState: Record<string, any>,
oldState: Record<string, any>
): Record<string, any> {
newState: Record<string, unknown>,
oldState: Record<string, unknown>
): Record<string, unknown> {
// no need to go through symbols because they cannot be serialized anyway
for (const key in oldState) {
const subPatch = oldState[key]
Expand Down Expand Up @@ -79,12 +79,12 @@ export function acceptHMRUpdate<
S extends StateTree = StateTree,
G extends _GettersTree<S> = _GettersTree<S>,
A = _ActionsTree,
>(initialUseStore: StoreDefinition<Id, S, G, A>, hot: any) {
>(initialUseStore: StoreDefinition<Id, S, G, A>, hot: unknown) {
// strip as much as possible from iife.prod
if (!__DEV__) {
return () => {}
}
Comment on lines +82 to 86
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

TypeScript error: accessing properties on unknown without narrowing.

Changing hot to unknown without adding type narrowing will cause TypeScript compilation errors at lines 88, 96, and 111 where hot.data and hot.invalidate() are accessed without first narrowing the type.

Consider these options:

Option 1: Keep any for the hot parameter (least disruptive):

->(initialUseStore: StoreDefinition<Id, S, G, A>, hot: unknown) {
+>(initialUseStore: StoreDefinition<Id, S, G, A>, hot: any) {

Option 2: Define a proper type for the HMR API:

interface HotModuleAPI {
  data: Record<string, any>
  invalidate(): void
}

export function acceptHMRUpdate<...>(
  initialUseStore: StoreDefinition<Id, S, G, A>, 
  hot: HotModuleAPI
) {

Option 3: Add runtime narrowing (if you want to keep unknown):

>(initialUseStore: StoreDefinition<Id, S, G, A>, hot: unknown) {
  if (!hot || typeof hot !== 'object') return () => {}
  if (!('data' in hot) || !('invalidate' in hot)) return () => {}
  // ... rest of implementation with type assertions
🤖 Prompt for AI Agents 
In packages/pinia/src/hmr.ts around lines 82 to 86, the function parameter hot
was changed to unknown but the code later (lines ~88, 96, 111) accesses hot.data
and hot.invalidate() without narrowing; update the code to use a proper HMR API
type instead of unknown: declare a HotModuleAPI interface (data: Record<string,
any>; invalidate(): void) and change the function signature to accept hot:
HotModuleAPI, then ensure any remaining runtime checks/assertions use that type;
alternatively, if you prefer minimal change, revert hot to any to avoid
TypeScript errors.

return (newModule: any) => {
return (newModule: unknown) => {
const pinia: Pinia | undefined = hot.data.pinia || initialUseStore._pinia

if (!pinia) {
Expand Down
5 changes: 2 additions & 3 deletions packages/pinia/src/types.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,14 +11,13 @@ import { Pinia } from './rootStore'
/**
* Generic state of a Store
*/
export type StateTree = Record<PropertyKey, any>
export type StateTree = Record<PropertyKey, unknown>

export function isPlainObject<S extends StateTree>(
value: S | unknown
): value is S
export function isPlainObject(
// eslint-disable-next-line @typescript-eslint/no-explicit-any
o: any
o: unknown
): o is StateTree {
return (
o &&
Expand Down
2 changes: 1 addition & 1 deletion packages/testing/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "@pinia/testing",
"version": "1.0.3",
"version": "1.0.4",
"description": "Testing module for Pinia",
"keywords": [
"vue",
Expand Down