The Node SEA executable should be a "bundler"

[ovflowd]

One of the beautiful things I image for the SEA feature within Node.js is to act as a bundler that:

• Bundles non-static code (Such as assets)
  • SEA would have a set of built-in loaders that support specific asset formats
  • Binary formats such as PDF, PNGs, et cetera could be optimized by default using well-known approaches, Lossless/Lossy
  • Non-binary formats such as JSON get transformed into a binary format through algorithms such as LZ4, gzip or et cetera
  • All final binary-chunks of the assets get ported within a VFS handled by formats such as tar, zip, asar, et cetera
• SEA would support a flags (options) through CLI
  • Neat: Pass a JSON/js configuration file eg.: sea.config.js
• JavaScript code gets compiled and then transpiled (?)
• Bundler would advise about the size of the resulting bundler, how much memory footprint it might result ... et cetera

What do you folks think about this?

[ljharb]

I see this project as more of an executable that contains a tarball - tar is a bundler in the sense you describe :-)

[ovflowd]

Well, sure, just throwing a random idea here 🙈

[sheplu]

do we want a new config file or put that into the package.json as a new optional field (which would be required in this case maybe) ?

[ovflowd]

do we want a new config file or put that into the package.json as a new optional field (which would be required in this case maybe) ?

Isn't the package.json more related for npm circumstances? I'd honestly have a different file just for these options.

[jviotti]

That doesn’t minimize the need for configuration overall tho

True. I'm just suggesting to not think about configuration options from the start with theoretical examples only, but think about them once we have real knobs we need to expose to potential users.

In #26, I'm starting to collect a list of CLIs that we will use for the base testing suite of our SEA work. Once we have a prototype we can run, we would try to package and run every one of those CLIs and see how it goes. I think doing that exercise will surface what configuration options we need to expose.

[jviotti]

Also btw, feel free to add any popular CLI that you might know about there

[jviotti]

I know @RaisinTen has some cool ideas on how to create a true testing suite based on those projects in the same way that Node.js runs canary builds on a set of blessed Node.js modules

[RaisinTen]

yea, I was referring to using https://github.com/nodejs/citgm (we do CITGM runs on semver-major PRs in core to get an estimate of how much breakage a change might cause). Dropped #26 (comment) on the PR to make sure that we document that too.

[jviotti]

JavaScript code gets compiled and then transpiled (?)

I think this would be accomplished by making the SEA tool interoperable with the plethora of other bundlers there. Attempting to implement the whole thing within SEAs might be overly complex and expand the surface of the project way too much

[jviotti]

Binary formats such as PDF, PNGs, et cetera could be optimized by default using well-known approaches, Lossless/Lossy

This is an interesting one. Do bundlers already take care of this? If so, making the SEA tool very interoperable might be the best way to go. Otherwise, it should at least be opt-out. For example, some people might want to embed the EXACT file for analysis purposes, etc

[ljharb]

SEAs aren’t the same as bundlers - they won’t be running in browsers, so they don’t suffer from those constraints. Bundlers don’t need to worry about “files” at runtime, but an SEA will.

[jviotti]

True. That is an interesting distinction we could explore. Maybe there is a place for a new "bundler" that is not web-oriented

[jviotti]

Or maybe that should just be i.e. WebPack plugins?

[ovflowd]

That's kind of what I was talking about. My idea of bundlers is just pieces/plugins of SEA that would handle numerous mime-types requiring special treatment, compression, interpolation or whatever. Imagine if I want to SEA a Node.js application but first transpile it with Gulp, TypeScript or Babel?

In the end, Babel/TSC et cetera would already give you minified JavaScript code for a Node.js application (I'm not talking about WebPack or Web-oriented outputs). Maybe I'm thinking this too much with a Web-oriented perspective, but still, I think that having plugins (or bundlers or whatever the name) that can deal with specific situations would be interesting.

[ljharb]

I think just a virtual filesystem on top of a tarball is the simplest approach - a node-based SEA doesn’t ever really need to ship a single file, but it does almost always need a filesystem.