Gathering detailed insights and metrics for @shellscape/esbuild-sass-plugin
Gathering detailed insights and metrics for @shellscape/esbuild-sass-plugin
Gathering detailed insights and metrics for @shellscape/esbuild-sass-plugin
Gathering detailed insights and metrics for @shellscape/esbuild-sass-plugin
npm install @shellscape/esbuild-sass-plugin
Typescript
Module System
Node Version
NPM Version
JavaScript (53.55%)
CSS (42.46%)
TypeScript (3.39%)
SCSS (0.28%)
HTML (0.27%)
Shell (0.03%)
Sass (0.03%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
158 Stars
275 Commits
42 Forks
2 Watchers
5 Branches
22 Contributors
Updated on Jul 02, 2025
Latest Version
2.4.4-patch.2
Package Id
@shellscape/esbuild-sass-plugin@2.4.4-patch.2
Unpacked Size
51.67 kB
Size
15.22 kB
File Count
18
NPM Version
8.15.0
Node Version
16.17.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
A plugin for esbuild to handle Sass & SCSS files.
dynamic style
to be added to the html pagetype
has been simplified and now accepts only a string. If you need different types in a project you can use more
than one instance of the plugin.
You can have a look at the multiple fixture
for an example where lit CSS and CSS modules are both used in the same app1$ npm i esbuild-sass-plugin
Just add it to your esbuild plugins:
1import {sassPlugin} from 'esbuild-sass-plugin' 2 3await esbuild.build({ 4 ... 5 plugins: [sassPlugin()] 6})
There are two main options that control the plugin: filter
which has the same meaning of filter in esbuild
onLoad and type
that's what specifies how the css should be
rendered and imported.
The example above uses the default type css
and will use esbuild CSS loader so your transpiled Sass
will be in index.css
alongside your bundle.
In all other cases esbuild
won't process the CSS content which instead will be handled by the plugin.
if you want
url()
resolution or other processing you have to usepostcss
like in this example
type: "style"
In this mode the stylesheet will be in the javascript bundle and will be dynamically added to the page when the bundle is loaded.
type: "css-text"
You can use this mode if you want to use the resulting css text as a string import
1await esbuild.build({ 2 ... 3 plugins: [sassPlugin({ 4 type: "css-text", 5 ... // for the options availanle look at 'SassPluginOptions' in index.ts 6 })] 7})
...and in your module do something like
1import cssText from './styles.scss' 2 3customElements.define('hello-world', class HelloWorld extends HTMLElement { 4 constructor() { 5 super(); 6 this.attachShadow({mode: 'open'}); 7 this.sheet = new CSSStyleSheet(); 8 this.sheet.replaceSync(cssText); 9 this.shadowRoot.adoptedStyleSheets = [this.sheet]; 10 } 11}
type: "lit-css"
Or you can import a lit-element css result using type: "lit-css"
1import styles from './styles.scss' 2 3@customElement("hello-world") 4export default class HelloWorld extends LitElement { 5 6 static styles = styles 7 8 render() { 9 ... 10 } 11}
Look in test/fixtures
folder for more usage examples.
The options passed to the plugin are a superset of Sass compile string options.
Option | Type | Default |
---|---|---|
filter | regular expression | /.(s[ac]ss|css)$/ |
cache | boolean or Map | true (there is one Map per namespace) |
type | "css" "style" "lit-css" "css-text" | "css" |
transform | function | undefined |
loadPaths | string[] | [] |
precompile | function | undefined |
importMapper | function | undefined |
cssImports | boolean | false |
nonce | string | undefined |
prefer | string | preferred package.json field |
quietDeps | boolean | false |
exclude
?the option has been removed in favour of using filter
. The default filter is quite simple but also quite permissive.
If you have URLs in your imports and you want the plugin to ignore them you can just change the filter to something like:
1sassPlugin({ 2 filter: /^(?!https?:).*\.(s[ac]ss|css)$/ 3 ... 4})
cssImports
when this is set to true
the plugin rewrites the node-modules relative URLs startig with the ~
prefix so that
esbuild can resolve them similarly to what css-loader
does.
Although this practice is kind of deprecated nowadays some packages out there still use this notation (e.g.
formio
)
so I added this feature to help in cases like this one.
nonce
in presence of Content-Security-Policy
(CSP)
the nonce
option allows to specify the nonce attribute for the dynamically generated <style>
If the nonce
string is a field access starting with window
, process
or globalThis
it is left in the code without quotes.
1sassPlugin({ 2 type: 'style', 3 nonce: 'window.__esbuild_nonce__' 4})
This allows to define it globally or to leave it for a subsequent build to resolve it using esbuild define.
1define: {'window.__esbuild_nonce__': '"12345"'}
prefer
when this option is specified it allows to import npm packages which have sass
or style
fields preferring those to main
.
NOTE: This is an experimental feature
- it replaces the internal use of
require.resolve
with browserifyresolve.sync
- it only applies to import prefixed by
~
importMapper
A function to customize/re-map the import path, both import
statements in JavaScript/TypeScript code and @import
in Sass/SCSS are covered.
You can use this option to re-map import paths like tsconfig's paths
option.
e.g. given this tsconfig.json
which maps image files paths
1{ 2 "compilerOptions": { 3 "baseUrl": ".", 4 "paths": { 5 "@img/*": [ 6 "./assets/images/*" 7 ] 8 } 9 } 10}
now you can resolve these paths with importMapper
1await esbuild.build({ 2 ..., 3 plugins: [sassPlugin({ 4 importMapper: (path) => path.replace(/^@img\//, './assets/images/') 5 })] 6})
precompile
url(...)
sIf your sass reference resources with relative urls (see #48) esbuild will struggle to rewrite those urls because it doesn't have idea of the imports that the Sass compiler has gone through. Fortunately the new importer API allows to rewrite those relative URLs in absolute ones which then esbuild will be able to handle.
Here is an example of how to do the url(...)
rewrite (make sure to handle \
in Windows)
1const path = require('path') 2 3await esbuild.build({ 4 ..., 5 plugins: [sassPlugin({ 6 precompile(source, pathname) { 7 const basedir = path.dirname(pathname) 8 return source.replace(/(url\(['"]?)(\.\.?\/)([^'")]+['"]?\))/g, `$1${basedir}/$2$3`) 9 } 10 })] 11})
Look for a complete example in the precompile fixture.
Prepending a variable for a specific pathname
:
1const context = { color: "blue" } 2 3await esbuild.build({ 4 ..., 5 plugins: [sassPlugin({ 6 precompile(source, pathname) { 7 const prefix = /\/included\.scss$/.test(pathname) ? ` 8 $color: ${context.color}; 9 ` : env 10 return prefix + source 11 } 12 })] 13})
Prepending an @import
of globals file only for the root file that triggered the compilation (to avoid nested files from importing it again):
1const context = { color: "blue" } 2 3await esbuild.build({ 4 ..., 5 plugins: [sassPlugin({ 6 precompile(source, pathname, isRoot) { 7 return isRoot ? `@import '/path/to/globals.scss';\n${source}` : source 8 } 9 })] 10})
transform
1async (this: SassPluginOptions, css: string, resolveDir?: string) => Promise<string>
It's a function which will be invoked before passing the css to esbuild or wrapping it in a module.
It can be used to do PostCSS processing and/or to create modules like in the following examples.
NOTE: Since
v1.5.0
transform can return either a string or an esbuildLoadResult
object.
This is whatpostcssModules
uses to pass Javascript modules to esbuild bypassing the plugin output altogether.
The simplest use case is to invoke PostCSS like this:
1const postcss = require('postcss') 2const autoprefixer = require('autoprefixer') 3const postcssPresetEnv = require('postcss-preset-env') 4 5esbuild.build({ 6 ..., 7 plugins: [sassPlugin({ 8 async transform(source, resolveDir) { 9 const {css} = await postcss([autoprefixer, postcssPresetEnv({stage: 0})]).process(source) 10 return css 11 } 12 })] 13}) 14
A helper function is available to do all the work of calling PostCSS to create a CSS module. The usage is something like:
1const {sassPlugin, postcssModules} = require('esbuild-sass-plugin') 2 3esbuild.build({ 4 ..., 5 plugins: [sassPlugin({ 6 transform: postcssModules({ 7 // ...put here the options for postcss-modules: https://github.com/madyankin/postcss-modules 8 }) 9 })] 10}) 11
postcssModules
produces Javascript modules which are handled by esbuild's js
loader, so the type
option is ignored
postcssModules
also accepts an optional array of plugins for PostCSS as second parameter.
Look into fixture/css-modules for the complete example.
NOTE:
postcss
andpostcss-modules
have to be added to yourpackage.json
.
In order for quietDeps
to correctly identify external dependencies the url
option is defaulted to the importing file path URL.
The
url
option creates problems when importing source SASS files from 3rd party modules in which case the best workaround is to avoidquietDeps
and mute the logger if that's a big issue.
There's a working example of using pnpm
with @material
design
in issue/38
Windows 10 Pro - i7-4770K CPU @ 3.50GHz - RAM 24GB - SSD 500GB
Given 24 × 24 = 576 lit-element files & 576 imported CSS styles plus the import of the full bootstrap 5.1
dart sass | dart sass (no cache) | node-sass* | node-sass (no cache) | |
---|---|---|---|---|
initial build | 2.750s | 2.750s | 1.903s | 1.858s |
rebuild (.ts change) | 285.959ms | 1.950s | 797.098ms | 1.689s |
rebuild (.ts change) | 260.791ms | 1.799s | 768.213ms | 1.790s |
rebuild (.scss change) | 234.152ms | 1.801s | 770.619ms | 1.652s |
rebuild (.scss change) | 267.857ms | 1.738s | 750.743ms | 1.682s |
(*) node-sass is here just to give a term of comparison ...those samples were taken from 1.8.x
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
packaging workflow detected
Details
Reason
Found 6/20 approved changesets -- score normalized to 3
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
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
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
40 existing vulnerabilities detected
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