glromeo / esbuild-sass-plugin

esbuild plugin for sass
MIT License
155 stars 40 forks source link

nonce global issue #76

Closed rhu25 closed 2 years ago

rhu25 commented 2 years ago

Hi Gianluca,

thanks for your update for nonce previously. we have another a issue with nonce

we use esbuild-sass-plugin like this,

app A has app B as dependency, app B used esbuild-sass-plugin to esbuild.

following code is app B code

esbuild.build({
  entryPoints: ['src/index.ts'],
  outdir: 'dist/esm',
  bundle: true,
  sourcemap: true,
  minify: true,
  splitting: true,
  format: 'esm',
  target: 'esnext',
  plugins: [nodeExternalsPlugin(), sassPlugin({
    type: 'style',
  })],
})

since nonce need to be dynamic for each app used app B. we cant just hardcoded nonce like this

esbuild.build({
  entryPoints: ['src/index.ts'],
  outdir: 'dist/esm',
  bundle: true,
  sourcemap: true,
  minify: true,
  splitting: true,
  format: 'esm',
  target: 'esnext',
  plugins: [nodeExternalsPlugin(), sassPlugin({
    type: 'style',
    nonce:'12345'
  })],
})

so is possible to fix this line (if nonce not pass) to

style.setAttribute("nonce", window.__esbuild_nonce__);

so in this way its very easy to config in app A, just add

window.__esbuild_nonce__ = "dynamic_12345"

since i cant find esbuild_nonce in esbuild, so i just make this variable up, but webpack has `webpack_nonce`

thanks

@glromeo

glromeo commented 2 years ago

bitmoji

I rather not pollute the window scope for that...

How about we make so that you can bundle AppB leaving nonce unresolved and then bundle AppA using define?

In theory, this means you need to have two build target for your AppB one for when you want to use it standalone (if you do) and one for when it has to be re-bundled in AppA.

Suppose you pass in AppB build

sassPlugin({  ..., type: "style", nonce: "window.__whatever__" })

then it leaves __whatever__ accessed globally and unresolved.

You can call it __esbuild_nonce__ if you prefer, the code will just check that the string is a global field access.

At this point you can specify window.__whatever__ = "1234..." and that would work as you intended, but you can also just bundle AppA passing define: { "__whatever__": '"1234..."' } and that avoids polluting the global scope.

rhu25 commented 2 years ago

it works for me thank you very much

On Tue, Mar 29, 2022 at 12:18 AM Gianluca Romeo @.***> wrote:

[image: bitmoji] https://camo.githubusercontent.com/411d2c1dfad25cdc94dc33749b3ae4bd1b06cb5419a0532b86f54efdd1073978/68747470733a2f2f73646b2e6269746d6f6a692e636f6d2f72656e6465722f70616e656c2f37653362633435332d363466622d346133342d626361612d3438313732346535643364392d37373462663138342d626331632d346634382d613632372d3833363137323061666131302d76312e706e673f7472616e73706172656e743d312670616c657474653d312677696474683d323436

I rather not pollute the window scope for that...

How about we make so that you can bundle AppB leaving nonce unresolved and then bundle AppA using define?

In theory, this means you need to have two build target for your AppB one for when you want to use it standalone (if you do) and one for when it has to be re-bundled in AppA.

Suppose you pass in AppB build

{ "nonce": "whatever" }

then it leaves whatever accessed globally and unresolved. (call it __esbuild_nonce if you prefer, assume the code will just look at the string starting with ).

At this point you can specify window.whatever = "1234..." and that would work as you intended, but you can also just bundle AppA passing define: { "whatever": "1234..." } and that avoids polluting the global scope.

— Reply to this email directly, view it on GitHub https://github.com/glromeo/esbuild-sass-plugin/issues/76#issuecomment-1080849915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEA6CIVBOYRV2PJ4SLKC7P3VCHLTPANCNFSM5R2DZIZA . You are receiving this because you authored the thread.Message ID: @.***>

rhu25 commented 2 years ago

Hi Gianluca,

I created a new issue for esbuild, https://github.com/glromeo/esbuild-sass-plugin/issues/79

Thanks, Ran

RAN HU @.***>于2022年3月29日 周二10:08写道:

it works for me thank you very much

On Tue, Mar 29, 2022 at 12:18 AM Gianluca Romeo @.***> wrote:

[image: bitmoji] https://camo.githubusercontent.com/411d2c1dfad25cdc94dc33749b3ae4bd1b06cb5419a0532b86f54efdd1073978/68747470733a2f2f73646b2e6269746d6f6a692e636f6d2f72656e6465722f70616e656c2f37653362633435332d363466622d346133342d626361612d3438313732346535643364392d37373462663138342d626331632d346634382d613632372d3833363137323061666131302d76312e706e673f7472616e73706172656e743d312670616c657474653d312677696474683d323436

I rather not pollute the window scope for that...

How about we make so that you can bundle AppB leaving nonce unresolved and then bundle AppA using define?

In theory, this means you need to have two build target for your AppB one for when you want to use it standalone (if you do) and one for when it has to be re-bundled in AppA.

Suppose you pass in AppB build

{ "nonce": "whatever" }

then it leaves whatever accessed globally and unresolved. (call it __esbuild_nonce if you prefer, assume the code will just look at the string starting with ).

At this point you can specify window.whatever = "1234..." and that would work as you intended, but you can also just bundle AppA passing define: { "whatever": "1234..." } and that avoids polluting the global scope.

— Reply to this email directly, view it on GitHub https://github.com/glromeo/esbuild-sass-plugin/issues/76#issuecomment-1080849915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEA6CIVBOYRV2PJ4SLKC7P3VCHLTPANCNFSM5R2DZIZA . You are receiving this because you authored the thread.Message ID: @.***>