solid/reactivity
hardcodes the assumption that solid primitives are imported from "solid-js"
#183
Labels
enhancement
New feature or request
Describe the need
semi-related to: solidjs/solid-refresh#44
In our codebase, we use a universal renderer that explicitly skips the web-specific features present in
"solid-js"
. this means, instead of writingimport {createSignal} from 'solid-js'
, we writeimport {createSignal} from 'my-custom-solid-renderer';
This kind of accidentally worked in earlier versions of eslint-plugin-solid, but it seems that in-between 0.13.2 and 0.14.5, the symbol detection got more strict, leading to many more false negatives.
Suggested Solution
some kind of config option to specify the import path, eg. solidImportPattern: /^my-custom-solid-renderer/
this would involve adding a parameter to the
trackImports()
method and adding this config flag to every rule that uses it. (I don't know eslint that well, but if this could be a global parser flag ala the tsconfig that would probably be better)https://github.com/solidjs-community/eslint-plugin-solid/blob/main/packages/eslint-plugin-solid/src/utils.ts#L149
Possible Alternatives
the upstream solid package could be refactored to not be web-specific, or for the reactive pieces to exist in their own library (solidjs/solid#2051). i think this is already happening for solid 2.
we could remove the requirement altogether that imports come from the solid-js library, but i think that would be worse for all other users.
The text was updated successfully, but these errors were encountered: