That's the kind of stuff you'd want to test because it can change over time/there might be bugs/edge cases/specificities depending on your package

you can output a bundle analysis

the recent change (can tell the exact version) is that now Next.js automatically handles libs with "barrel" files, namely lodash, out of the box

btw - this came along with React 17 jsx transforms. You don't need to import react from 'react' with next

I also use the "Import Cost" extension - some libraries may not be configured correctly for treeshaking

Does import cost account for next’s ability to force modularized imports?

i assume not

still a cool extension tho

Not sure what you mean by modularized import, if it ends up generating multiple isolated JS chunks then I think it should?

anyway last time I've checked I could see page specific code, layout specific code, dynamic JS chunks etc.

but I didn't use it recently, I need to check again

i never checked this in more details so this most likely is wrong, but somehow i feel like import React from "react", import { useState } from "react" and import * as React from "react" all have the same impact on bundle size

not based on any technical reasons but simply because, if one way is better than the others, why are all of them still used by many people

it's been quite a while since import React from "react" is no longer required

The jsx transform basically puts import react from "react" at the top of all the files for you

so, functionally the same

i see, that's interesting