Webpack.js.org: API - "lazy-once" Option Unclear

[catamphetamine]

"lazy-once": Generates a single lazy-loadable chunk that can satisfy all calls to import(). The chunk will be fetched on the first call to import(), and subsequent calls to import() will use the same network response. Note that this only makes sense in the case of a partially dynamic statement, e.g. import(./locales/${language}.json), where there are multiple module paths that could potentially be requested.

So why does it "only make sense in the case of a partially dynamic statement"?
Why does it make sense to fetch non-partially-dynamic statement every time it's import()ed?
Seems counter-productive.
If you fetched a module once why fetch it again.

[skipjack]

So why does it "only make sense in the case of a partially dynamic statement"?

Because if you only have one bundle, then there's nothing to roll up. A partially dynamic statement (the only kind of dynamic statement allowed) will potentially resolve to multiple files which -- by default -- are separated into separate bundles. "lazy-once" will roll these bundles into a single bundle which is only pulled once.

Why does it make sense to fetch non-partially-dynamic statement every time it's import()ed?

It doesn't, though I guess I get how someone reading this could come to that conclusion based on how it's phrased. I think we should lump this in with #1699 as well. A PR to clarify all this would be great.

Would you be interested in submitting a PR to resolve both or even just this issue? Feel free to use my explanation above if it makes sense to you.

[catamphetamine]

@skipjack thanks for detailed responses

Because if you only have one bundle, then there's nothing to roll up. A partially dynamic statement (the only kind of dynamic statement allowed) will potentially resolve to multiple files which -- by default -- are separated into separate bundles. "lazy-once" will roll these bundles into a single bundle which is only pulled once.

Hmm, so if I'm guessing it right lazy still doesn't re-download bundles, and the only difference with lazy-once is that it downloads the whole bundle. I guess it's the not-so-descriptive naming then, because otherwise lazy === lazy-multiple. lazy-once should have been named something like lazy-bulk.

I would rewrite this part of the documentation but I'm not sure if I'm qualified to do that.
Anyway, that's how I would do it:

"lazy-once": The naming of this one is not so good. What it does is it generates a single lazy-loadable chunk for a "dynamic" import like import(./pages/HomePage.${language}.json). The default lazy would create a separate chunk for each language, but when import()ed with lazy-once it would create a single chunk for all languages. Why would anyone need that? I don't know.

As for the "dynamic imports" discussion I would call things like import(./pages/HomePage.${language}.json) a "dynamic import" and call import() an "asynchronous import", or "external import", or something like that.
It's just my personal preference and I don't think "dynamic" is the right word for a "static" (fixed, idempotent, constant string name) import that is just a "lazy" one.

Anyway, I didn't expect to get such detailed answers to my questions and you're doing a great job here. Don't even know how much time it takes. While I acknowledge the importance of this whole thing, I'm not ready to take part in it and submit PRs to documentation (and I won't pretend I'm "too busy right now"), so I guess you're on your own here.
Maybe you could just hyperlink the lazy-once word in the documentation to this github issue and that would be poor man's docs on lazy-once.

Same with "import(./pages/HomePage.${language}.json)" - we could get away without dedicating a whole new section to it and instead just replacing

Every module that could potentially be requested on an import() call is included. For example, import(./locale/${language}.json) will cause every .json file in the ./locale directory to be bundled into the new chunk. At run time, when the variable language has been computed, any file like english.json or german.json will be available for consumption.

With

Every module that could potentially be requested on an import() call is included. For example, import(./pages/HomePage.${language}.json) will cause every HomePage.*.json file in the ./pages directory to be bundled into the new chunk. At run time, when the variable language has been computed, any file like english.json or german.json will be available for consumption.

And call it a day.

[skipjack]

I guess it's the not-so-descriptive naming then, because otherwise lazy === lazy-multiple. lazy-once should have been named something like lazy-bulk.

Yeah lazy-bulk might be a better name for it, I'd recommend creating an issue on the main repo if you want to push that forward. You may even be able to sneak it in before the final v4 release.

Anyway, that's how I would do it...

Hahaha, yeah I'd drop the "naming of this one is not so good" part as that's kind of a bad look for us but I'm totally open to rephrasing this a bit to make it more clear. The rest of what you had wasn't bad.

Anyway, I didn't expect to get such detailed answers to my questions and you're doing a great job here. Don't even know how much time it takes. While I acknowledge the importance of this whole thing, I'm not ready to take part in it and submit PRs...

Thanks, webpack does have a broad public API which makes documenting it all and keeping the docs up to date a tough job. I hope you stick with the tool and you should always feel free to submit a PR (whether large or small) here or on the main repo. I'll try to resolve both this and #1699 soon.

[catamphetamine]

Created an issue in the main repo for lazy-bulk.
Closing this one.

[bebraw]

The issue for reference, https://github.com/webpack/webpack/issues/6439 .