Gathering detailed insights and metrics for sdwvit-eslint-plugin-svelte3
Gathering detailed insights and metrics for sdwvit-eslint-plugin-svelte3
Gathering detailed insights and metrics for sdwvit-eslint-plugin-svelte3
Gathering detailed insights and metrics for sdwvit-eslint-plugin-svelte3
An ESLint plugin for Svelte v3 components.
npm install sdwvit-eslint-plugin-svelte3
Typescript
Module System
Node Version
NPM Version
JavaScript (81%)
Svelte (18.51%)
TypeScript (0.49%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
373 Stars
193 Commits
43 Forks
14 Watchers
1 Branches
24 Contributors
Updated on Jul 03, 2025
Latest Version
2.7.3-preprocess
Package Id
sdwvit-eslint-plugin-svelte3@2.7.3-preprocess
Unpacked Size
25.37 kB
Size
8.61 kB
File Count
5
NPM Version
6.13.4
Node Version
12.16.0
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
An ESLint plugin for Svelte v3 components.
$:
labels are always allowed, regardless of configurationInstall the plugin package:
npm install --save-dev eslint-plugin-svelte3
Then add svelte3
to the plugins
array in your .eslintrc.*
, and set svelte3/svelte3
as the processor
for your Svelte components.
For example:
1module.exports = { 2 parserOptions: { 3 ecmaVersion: 2019, 4 sourceType: 'module' 5 }, 6 env: { 7 es6: true, 8 browser: true 9 }, 10 plugins: [ 11 'svelte3' 12 ], 13 overrides: [ 14 { 15 files: ['*.svelte'], 16 processor: 'svelte3/svelte3' 17 } 18 ], 19 rules: { 20 // ... 21 }, 22 settings: { 23 // ... 24 } 25};
By default, this plugin needs to be able to require('svelte/compiler')
. If ESLint, this plugin, and Svelte are all installed locally in your project, this should not be a problem.
Care needs to be taken when using this plugin alongside others. Take a look at this list of things you need to watch out for.
There are a few settings you can use to adjust this plugin's behavior. These go in the settings
object in your ESLint configuration.
Passing a function as a value for a setting (which some of the settings below require) is only possible when using a CommonJS .eslintrc.js
file, and not a JSON or YAML configuration file.
svelte3/ignore-warnings
This setting can be given a function that indicates whether to ignore a warning in the linting. The function will be passed a warning object and should return a boolean.
The default is to not ignore any warnings.
svelte3/compiler-options
Most compiler options do not affect the validity of compiled components, but a couple of them can. If you are compiling to custom elements, or for some other reason need to control how the plugin compiles the components it's linting, you can use this setting.
This setting can be given an object of compiler options.
The default is to compile with { generate: false }
.
svelte3/ignore-styles
If you're using some sort of preprocessor on the component styles, then it's likely that when this plugin calls the Svelte compiler on your component, it will throw an exception. In a perfect world, this plugin would be able to apply the preprocessor to the component and then use source maps to translate any warnings back to the original source. In the current reality, however, you can instead simply disregard styles written in anything other than standard CSS. You won't get warnings about the styles from the linter, but your application will still use them (of course) and compiler warnings will still appear in your build logs.
This setting can be given a function that accepts an object of attributes on a <style>
tag (like that passed to a Svelte preprocessor) and returns whether to ignore the style block for the purposes of linting.
The default is to not ignore any styles.
svelte3/named-blocks
When an ESLint processor processes a file, it is able to output named code blocks, which can each have their own linting configuration. When this setting is enabled, the code extracted from <script context='module'>
tag, the <script>
tag, and the template are respectively given the block names module.js
, instance.js
, and template.js
.
This means that to override linting rules in Svelte components, you'd instead have to target **/*.svelte/*.js
. But it also means that you can define an override targeting **/*.svelte/*_template.js
for example, and that configuration will only apply to linting done on the templates in Svelte components.
The default is to not use named code blocks.
svelte3/compiler
In some esoteric setups, this plugin might not be able to find the correct instance of the Svelte compiler to use.
This setting can be given the result of require('.../path/to/svelte/compiler')
to indicate which instance should be used in linting the components.
The default is require('svelte/compiler')
from wherever the plugin is installed to.
svelte3/preprocess
You can use a preprocessor function to return custom AST info according to the original code.
For now this only supports module
and instance
scripts.
It's probably a good idea to make sure you can lint from the command line before proceeding with configuring your editor.
Using this with the command line eslint
tool shouldn't require any special actions. Just remember that if you are running eslint
on a directory, you need to pass it the --ext
flag to tell it which nonstandard file extensions you want to lint.
See INTEGRATIONS.md for how to use this plugin with your text editor.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
Found 13/30 approved changesets -- score normalized to 4
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More