-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bundles #199
Conversation
A 'pure replayer' bundle seems moving to the side of explosive combinations. If we adopt that, we also need 'pure unpack' bundle and 'pure unpack + replayer' bundle:) Let bundlers do that stuff seems a better choice:) |
I assume the use case for that would be to run it on the server in order to decompress prior to storage? If that's the case then I don't see why it should be generated in the |
Note on naming:
From my understanding, here's another possibilitiy (have omitted minified and .map and css for simplicity):
|
@eoghanmurray I very much love your naming/logic proposal. @Yuyz0112 is there any chance you guys can adopt the bundle logic that @eoghanmurray is proposing here above? |
Hi @MaheshCasiraghi @eoghanmurray, I'm trying to make the bundle files look like @eoghanmurray 's suggestion. And the new minor version(0.8.0) will be released after this. |
Now it looks like this:
|
According to @eoghanmurray's suggestion, we can support three main scenarios: 1. record only 2. replay only 3. all in one Since we have implemented the packer feature, which has a big influence in bundle size, we provide another three bundles: 1. record and pack 2. replay and unpack 3. all in one with pack and unpack
With some further discussions in #151, now I plan to provide the following bundle outputs.
Under this config, the
dist
directory (iife output) looks like this:And I change the CommonJS and es module entry point to the all in one file: boost.ts. So module users can still import from a single line: