Reduce bundle size, when using a flag that does not depend on

[kazupon]

Describe the feature

What to Expect

If we use this flag, providers will be bundled, but even if we use a flag that does not depend on providers, such as isWindows, they will still be bundled.

If they do not depend on it, we expect them not to be bundled.

Also, if you use isCI, all providers' code will be bundled. It might be nice to have a way for users to resolve providers themselves by exporting an API that resolves them.

Reproduction repo

https://github.com/kazupon/std-env-repro1

Related

rolldown/rolldown#754 (comment)

Additional information

• Would you be willing to help implement this feature?

[pi0]

Thanks for nice reproduction.

I have made #130 in attempt to see how we can optimize more.

TLDR is, rollup does not trust only sideEffects: true field of package.json, we need to annotate internals calls like new Proxy() constructor even with /* @__PURE__ */ comment to tell rollup tree-shake them and in minified build of std-env esbuilds removes them and ALSO we need to opt-in to an unsafe rollup tree-shake option to even be able to leverage it.

With changes of linked PR and custom unbuild configuration below, you can see isWindows can be tree-shaken only:

import { defineBuildConfig } from 'unbuild'

export default defineBuildConfig({
    entries: [
        // 'src/ci.ts',
        'src/windows.ts'
    ],
    rollup: {
        inlineDependencies: true,
    },
    hooks: {
        "rollup:options"(_ctx, options) {
            options.treeshake = 'smallest'
        }
    }
})

---

At this point, I really think it is best for the majority of the ecosystem that we keep shipping one minified dist. 1kB extra in CLI bundle is relatively better than doing any other over engineering IMO and many flags even isCI needs provider information which takes main portion of this.

[kazupon]

Thank you for your kind reply.

I understand that unjs is also used in other ecosystems, including nuxt.
The effort to remove providers for a 1KB reduction is indeed over-engineering for unjs, as you say.

isCI flag, and other flags that depend on it, can be implemented in an existing another way, so it certainly doesn't make sense to over-engineer it for my use case for unjs.

I appreciate you are making experimenting PR & giving unbuild config :)