https://github.com/umbraco/Umbraco-CMS/blob/main/templates/UmbracoExtension/Client/vite.config.ts#L12 vite.config.ts...

sourcemaps:true

? should this be

false

for a package release? Or does it depend on consumption.. eg usually backoffice so mitigated?

Personally, I find them useful for debugging and/or submitting issue reports. They are only loaded if a person opens DevTools in their browser anyway.

They got flagged in a review..

Source maps expose your original, unminified source code, including comments, variable names, and internal logic, which poses a security risk if your package contains proprietary code or sensitive implementation details.

Yes, depends on your security requirements. For open source packages, the source code is there on Github anyway. Generally, if you use tools like Sentry.io, they would also like to have the source maps to show you where the errors happen

if that's the case then why bloat the package with sourcemaps? presumably any tool can prettify?

It allows you to set breakpoints in your own source code, for instance. And for tools like Sentry, it will give you the actual line in the actual source file where an error popped up.

Cheers, I'll feedback those pros and cons.

It comes down to whether you think it is useful. Regardless if you find it valuable or not, I would not deem it as a security concern because of the reasons above: you can prettify mangled code anyway, and you have bigger trouble if hiding your source code is a concern to you. JavaScript will never be compiled anyway.

I wonder if it's more the commenting that minification removes.. flappy lips and all that? at least to watch out for.

don't your package ship with the d.ts declaration files from Typescript anyway? they contain the comments and everything, and they are also serveable in a default web server

can't see anything in the nugetpackage explorer that suggests d.ts files are present...

depends if you have

declaration: true

set in tsconfig.json

and actually the .element-xxxxxx.js files don't appear to be minified.. at least not single line.

it says here https://vite.dev/config/build-options#build-minify that > Note the build.minify option does not minify whitespaces when using the 'es' format in lib mode, as it removes pure annotations and breaks tree-shaking.

right back to just seeing it as a blackbox and not investigating too closely... 🙂

Yeah, but no it's a good point, though. In your case, you presumably just want your library to load and you are not concerned with tree-shaking because you only ship what should be loaded in production anyway. I wonder if "es" is the best mode for that or if "umd" would not be better. But not sure the Backoffice knows how to load anything other than es modules.

not from umbraco, but a global way to override the vite version stamp

oh, I see, but that is really only relevant if you publish to npmjs.com

can't see that it ends up in the compiled files.. so prob not.. thought it might be a cache busting approach..

Vite generates a new hash every time you build, so that works as cache-busting. However, your main entry point in the

extensions: []

array is likely not hashed, so you'd want to set some kind of

?v=x.y.z

on that in umbraco-package.json

Is that arbitrary.. new hash every build no matter if no code change? Just checked and no must be based on something as repeat builds hash remains constant.. code change and the relevant genrated filehash does change... 🙂 guessing filecontents as reverting the change and same hash re-appears.

yeah, there is a cache somewhere of the contents, I believe

thanks for your time and insight!