[FEATURE] Cleaner output for code scanning tools

[kenchris]

Some enterprise companies requires code scans before publishing new projects, where pieces of code is matched to approved projects. One popular tool for this is Blackduck Protex.

The build output of snowpack created commons/ with files that include mangled up code from multiple projects plus it can be quite hard to know what code belongs to what node_modules module given the names.

A different output option that doesn't mangle code up in commons or at least not from multiple projects would be quite useful. It might also be useful to add a small comment inside each source file linking to the originating node_modules module.

[natemoo-re]

Thanks for opening an issue! Are you using @snowpack/plugin-webpack or the optimize option in snowpack.config.js? I believe those could be the source of this behavior.

If not, we have made some changes to the way packages are structured in snowpack@3.1.0. The output should look more like a typical node_modules directory. Can you give snowpack@next a spin and see if this is still an issue?

[kenchris]

No, I have been using snowpack < 3.0 with rollup and now I am using the latest released version with esbuild. Same behavior.

With optimize in 3.x I am disabling bundling, splitting, treeshaking etc.

module.exports = {
  optimize: {
    target: "es2020",
    sourcemap: "external",
    bundle: false,
    minify: false,
    splitting: false,
    treeshake: false
  },

[kenchris]

I did npm install snowpack@next and got ^3.1.0-pre14 but even after cleaning node_modules and reinstalling npx snowpack --version shows 3.0.13 - any idea how to fix this? :-)

[natemoo-re]

I did npm install snowpack@next and got ^3.1.0-pre14 but even after cleaning node_modules and reinstalling npx snowpack --version shows 3.0.13 - any idea how to fix this? :-)

Ooh, I think that's an issue on our end. Will take a look.

No, I have been using snowpack < 3.0 with rollup and now I am using the latest released version with esbuild. Same behavior.

With optimize in 3.x I am disabling bundling, splitting, treeshaking etc.

module.exports = {
  optimize: {
    target: "es2020",
    sourcemap: "external",
    bundle: false,
    minify: false,
    splitting: false,
    treeshake: false
  },

Hmm, what are you hoping the output looks like with these optimize settings? optimize is an optional step for bundling the final output. By setting everything to false, it seems like you prefer Snowpack's default "unbundled" output? Does removing optimize entirely look better?

We are still working on the way optimize works, but esbuild is definitely not as mature as webpack/rollup. If you need complete control over the bundling behavior, it might be best to stick with your rollup setup.

[natemoo-re]

Ah, ok, sorry, I think I misunderstood your request! common is automatically generated no matter what, so messing with those settings isn't going to help. I will circle back with the team and get their opinion on this.

When Snowpack runs, it automatically optimizes your dependencies—meaning we run rollup on them to convert everything to ESM get everything ready to work in the browser. That's when the common chunks are being generated.

[kenchris]

Yes, as if everything is bundled up the tools cannot identify the source and you cannot assign more than one module to each file.

Protex scan is a requirement by my employer before launching any software publicly.

Below you see how the output looks (a part of it) as you can see it is easy to identifying the source modules for files like mwc-button.js but not to something like observer-66f202ce.js - we need to match these to approved modules in the Protex tool

Other files like " class-map-9aa5b425.js" should come from lit-html but it contains Microsoft copyright which I believe is from tslib. I can personally track these down, but other team member have no idea how to do that. If at least the files could contain a comment which lists the source modules from node_modules - that would be a good help

├── _snowpack
│   └── pkg
│       ├── @material
│       │   ├── mwc-button.js
│       │   ├── mwc-formfield.js
│       │   ├── mwc-icon-button.js
│       │   ├── mwc-linear-progress.js
│       │   ├── mwc-switch.js
│       │   └── mwc-textfield.js
│       ├── common
│       │   ├── class-map-9aa5b425.js
│       │   ├── foundation-55886ece.js
│       │   ├── if-defined-b393f948.js
│       │   ├── lit-html-8547c331.js
│       │   ├── observer-66f202ce.js
│       │   └── ripple-handlers-4d82c385.js
│       ├── import-map.json
│       ├── lit-element
│       │   └── lib
│       │       └── decorators.js
│       ├── lit-element.js
│       ├── lit-html
│       │   └── directives
│       │       └── style-map.js
│       └── lit-html.js

[natemoo-re]

That makes total sense, thank you so much for the additional context! We definitely want to make it as easy as possible to use Snowpack at work! 😄 We will discuss this internally and I'll get back to you.

[FredKSchott]

Thanks again for filing @kenchris. Just curious, how important is performance for this use-case? Is this app that you're building user-facing? We could get away with using the "dev mode" package output in unbundled builds by default, and then leaving "optimize" to bundle appropriately. It's slower/bigger at runtime, but every package is self-contained.

This would have the added benefit of aligning dev & build, AND letting your bundler of choice handle this however you'd like (if the bundler is also bundling packages, then whatever you'd use to solve this with Webpack, Rollup, or esbuild would be reusable here).

[kenchris]

Performance is not important. We will probably use a different build output for the published app/site, but we need some non optimized build we can use for code scanning / approval process

It could thus be a different build output

Of course, the very best is that the final optimized build is generated from this output, to make sure no new deps are introduced in the built output