[#79] relative css injection improvements

[Codex-]

This is a bit chunky, i've abstracted a few chunks out that can be isolated and tested independently, but have not added any tests yet.

Have a play, and see what you think @marco-prontera

I imagine we'd want to move the abstracted methods into either utils or another file

[Codex-]

From here, just need to decide if we want the exported functions in their own file or with the other utils, I also found an oddity where this uses esbuild with an explicit target instead of using the one from the vite config, but can sort that in another PR :)

[marco-prontera]

First of all, thank you!
I wrote some comments that can improve this thing a little bit, and after that, I think we are ready!

[marco-prontera]

From here, just need to decide if we want the exported functions in their own file or with the other utils, I also found an oddity where this uses esbuild with an explicit target instead of using the one from the vite config, but can sort that in another PR :)

I opened an issue to track the thing about the 'build.target'!

I think we can write named functions instead of anonymous functions because it makes debugging more difficult. And moving all the functions from the top to the bottom of the file will make it a little more readable, do you agree?

[Codex-]

I opened an issue to track the thing about the 'build.target'!

Excellent, should be an easy fix :)

And moving all the functions from the top to the bottom of the file will make it a little more readable, do you agree?

Can do, did you want to keep these new functions in the file though? The problem is with keeping them there is that they're now exposed as part of the public API, ideally you want to import them from another file without re-exporting them and then only exporting the plugin / interfaces right?

[Codex-]

I think we can write named functions instead of anonymous functions because it makes debugging more difficult.

Which did you want to name? Any that are stored in a var actually return their name:

const someFunc = () => { throw new Error() };

> const someFunc = () => { throw new Error() };
undefined
> someFunc()
Uncaught Error
    at someFunc (REPL1:1:32)
> 

[marco-prontera]

I opened an issue to track the thing about the 'build.target'!

Excellent, should be an easy fix :)

And moving all the functions from the top to the bottom of the file will make it a little more readable, do you agree?

Can do, did you want to keep these new functions in the file though? The problem is with keeping them there is that they're now exposed as part of the public API, ideally you want to import them from another file without re-exporting them and then only exporting the plugin / interfaces right?

You are right, at this point, you can move also the functions that are now at the bottom also in the utils file.
For the anonymous functions question, I think it's better to give a name to functions used inside the filter and map calls (but it's not a problem)

[Codex-]

You are right, at this point, you can move also the functions that are now at the bottom also in the utils file. For the anonymous functions question, I think it's better to give a name to functions used inside the filter and map calls (but it's not a problem)

• Moved the helpers to utils
• Moved the tests to utils.spec
• Reorganised the existing tests a little.
• Updated some of the anonymous functions to be named.

[marco-prontera]

You are right, at this point, you can move also the functions that are now at the bottom also in the utils file. For the anonymous functions question, I think it's better to give a name to functions used inside the filter and map calls (but it's not a problem)

• Moved the helpers to utils
• Moved the tests to utils.spec
• Reorganised the existing tests a little.
• Updated some of the anonymous functions to be named.

Perfect!

[Codex-]

We should probably add something like:

#### relativeCSSInjection (boolean)

Enabling `relativeCSSInjection` will identify which JS assets import which CSS, and inject the imported CSS only to the directly related JS assets.

Any CSS assets not associated with a JS asset will be logged at the end of `relativeCSSInjection`, however, this can be suppressed by also setting `suppressUnusedCssWarning` to `true`.

to the docs for this 🤔