serverside-rendering react app with code splitting using loadable-components

Question

I recently implemented serverside-rendering react app with code splitting using loadable-components

But it seems that loadable-components itself dependent on webpack, since loadable replaces jsonp_callback with its own reporter.

So what are the alternative options that we can use when using other bundlers like rollup, esbuild?

Do we have to manually walk through the react tree to pre configure which chunk is needed on which component unless there is no specific bundler targeted library like loadable-components when implementing code splitting on serverside rendering?

Answer 1

Is tsconfig typeRoots unnecessary?

First, let us consult the compiler options reference:

The documentation for typeRoots states (emphasis mine):

By default all visible @types packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible. For example, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.

If typeRoots is specified, only packages under typeRoots will be included.

That second line is important: if you don't set typeRoots then tsc defaults to looking for directories under node_modules containing @types in their directory names.

_{(The documentation doesn't say if it chooses node_modules because of the moduleResolution parameter though. (I suspect I'd need to dig-in tsc's source-code to find out for sure).)}

If you do set a value for typeRoots than that overrides tsc's node_modules/**/@types* lookup logic and it will then only look in the specified directories.

---

As I know, I have to specify the path of the above file into typeRoots option of tsconfig file since typeRoots defaults to look into the node_modules/@types.

Not necessarily. You could also add your extra typings files' locations to the paths parameter and leave the typeRoots parameter blank/un-set, which means tsc will retain the "node_modules/@types-and-ancestor-walking behavior" but will see your .d.ts files just fine.

This scenario is mentioned in this TypeScript GitHub thread: https://github.com/microsoft/TypeScript/issues/13581

---

So if you're asking about your specific local environment on your machine: and assuming that you're sticking with the normative, typical (I dare say mainstream) TypeScript working idioms (such as using npm) then yes: you can remove the typeRoots parameter because tsc's (current) default behavior is to look for node_modules directories in the same location as your tsconfig.json.

(I understand that VS Code might also be pulling some strings behind-the-scenes to make tsc "aware" of your project files and dependencies and for its language-server process - but that shouldn't matter as you'll notice tsc should work identically from the command-line outside of VS Code).

---

If you're asking about the fundamental necessity of the typeRoots compiler option, and supposing that you're thinking "that because practically everyone is using npm and node_modules then why is the TypeScript team spending their time supporting unusual development configurations?"_ - well, for many very good reasons: tools shouldn't be dependent on other tools controlled by third-parties1: Consider the possibility that the npm ecosystem and/or NodeJS software could fall out of fashion overnight and then we'd be stuck with tsc's defaults still using node_modules when everyone is rockin' some new cool JS environment: there'd be headaches for many years to resolve the mess (not that the JS ecosystem isn't a mess as it is).

And there are many good reasons to not use npm and node_modules: people could be using TypeScript in an environment without internet access (think: secure software development, the defence industry, national secrets, etc) - those people in those situations might have a network share full of approved or known-trustworthy libraries that won't be using node_modules's naming convention - in which case if those people want to use d.ts files they'll need to manually configure the typeRoots parameter for themselves.

---

1 I'm aware that npm (which is legally separate from NodeJS, btw) is maintained by npm Inc, which is a subsidary of Microsoft (by way of being acquired by GitHub, also a Microsoft property), so having tsc depend on npm shouldn't be a problem - but that's a very recent thing: Microsoft only acquired npm 18 months ago in March 2020 - and Microsoft could very well spin-off npm Inc - or run it into the ground and everyone switches to yarn. So regardless of the end legal owners of whatever tooling is currently popular, you don't want unnecessary dependencies like that.