Marking @exp packages as side effects-free for Webpack

[dbanisimov]

Thanks, team, for your great work on the new @exp packages!

One particular use case that I've been excited to try is simplified lazy loading of the libs in React apps. The idea is that with the new libs to properly lazy-load them one can safely rely on dynamic imports and components-based or routes-based code-splitting.

Unfortunately that doesn't work out of the box as expected, as webpack cannot do tree-shaking across dynamically imported chunks, as it cannot guarantee correctness due to possible side effects. E.g. this doesn't work:

// routeA.tsx
import { runTransaction } from 'firebase/firestore';

// routeB.tsx
import { writeBatch } from 'firebase/firestore';

// index.tsx
const RouteA = loadable(() => import('routeA'));
const RouteA = loadable(() => import('routeB'));

Both dynamic imports will be bundled in a common chunk.

This also applies to barrel files. Something like that cannot be tree-shaked:

// src/hooks/useStorage.tsx
import { getFirestore } from 'firebase/firestore';

// src/hooks/useFunctions.tsx
import { getFunctions } from 'firebase/functions';

// src/hooks/index.tsx
export { default as useStorage } from './useStorage.tsx';
export { default as useFunctions } from './useFunctions.tsx';

// otherFile.tsx
import { useStorage } from 'src/hooks';

The chunk generated for otherFile.tsx will include both functions and firestore, despite only the firestore being used.

Webpack allows packages to be marked as side-effects free. Imports from such packages can be tree-shaked even across dynamically imported chunks.

I did test it by marking firebase packages as free of side-effects via a module.rules flag. It seems to produce the expected result, at least for barrel files use case.

So, the question is - can @exp packages be marked as side effects-free? Judging by the new API, that seems reasonable and should result in a better tree-shaking, at least in Webpack.

[Feiyang1]

Firebase packages actually have side-effects, so it would be incorrect to assert them as side-effects free in the package.json. The side effect is used to register services and make them work together. For example, Firestore can talk to Auth without you passing Auth to Firestore explicitly.

So it's impossible to code split within the same product (e.g. splitting runTransactions() and writeBatch() from firestore into 2 different chunk ), but you should be able to code split different products (e.g. Functions and Storage) into different chunks as they use different import paths. I suspect that the side effect makes the barrel file not code splittable, so you may want to import directly from src/hooks/useStorage.tsx.

[dbanisimov]

Hm, my understanding was that just importing a firebase/* package has no side-effects, and that calls to get* or initialize* are actually registering the services.

Splitting within the package could've been useful, as, for example, I suspect it's a common scenario for an app to require only a single-document firestore reads on load, but transactions, batches, etc on deeper navigation.

[Feiyang1]

Importing a package actually does have side effect to support auto-initialization today. For example, Firestore can trigger Auth initialization without you explicitly calling getAuth() or initializeAuth().

That said, I agree making firebase packages side effects free will be very beneficial and make code splitting much more effective & flexible. We are actually removing the ability to auto-initialize Auth in #4714, so there might be a chance we can do it to other packages as well which will open the door to making them side effects free, but we will need to do some research and designing first.

I will take it to the team for discussion. Thank you for the feedback!

[Feiyang1]

@dbanisimov Is it possible to share your project(or just a simplified version) and the webpack config? I'm looking into making firebase packages side effects free, but I'm struggling to get build tools(webpack and esbuild) to generate desired chunks.

I had no luck with a contrived example with webpack 5 either:

// index.js
import('./a').then(({myHello}) => {
    myHello();
})

import('./b').then(({myHi}) => {
    myHi();
})

// a.js
import {hello} from './impl';

export function myHello(){
    hello();
}

// b.js
import {hi} from './impl';

export function myHi(){
    hi();
}

// impl.js
export function hello(){
    console.log('hello');
}

export function hi(){
    console.log('hi');
}

I expect to generate 3 chunks - bundle.js, chunk_a.js and chunk_b.js, where impl.js is split into chunk_a.js and chunk_b.js - hello() in chunk_a.js and hi() in chunk_b.js.

In reality though, impl.js is NOT split. Both hello() and hi() are included in chunk_a.js and chunk_b.js. Do you know what I'm missing? My webpack config

Here is my branch, in case anyone would like to try and give me some guidance.

You need to cd into the webpack folder, npm i or yarn, then run npm run build to build.

[dbanisimov]

@Feiyang1 somehow this produces an expected result: dbanisimov/playground@46e0a81

Making impl.ts a barrel that re-exports functions from individual modules somehow allows webpack to treat them separately. I don't have an idea why it is the case, as for side effects and exports analysis it should be the same. Could be a bug?

I wonder what the results would be if impl was a package in node_modules instead, with side-effects marked on the package.

[Feiyang1]

Ah, your branch works perfectly. Thanks for the bug link. According to this comment, it seems webpack is unable to split a single module into different chunks. I think that's why your branch works where you put hello and hi into their own modules.

So it seems to me that we won't be able to code split a single module even with sideEffects: false, i.e. splitting runTransaction and writeBatch from firebase/firestore into different chunks, because firebase packages are all packaged as a single rollup bundle/module.

As to your second example, which is splitting by modules (firebase/firestore and firebase/functions), I think it should work, but apparently it doesn't (here is my repro).

I only use Firestore in the dynamically imported file, but Auth, Functions are both included in the chunk. Marking them as sideEffects: false in their package.json in node_modules doesn't make any difference.

You said you made it work via a flag. Can you please share the config?