Compile only the import tree, not the entire directory

[granite bison]

Hello! I'm currently developing a web game with rollup and rollup-plugin-typescript. My game has a number of bundles that include different .ts files and have to be compiled separately. By default, typescript compiles every single .ts file that it founds in the project directory. And it does that for every bundle that I compile. (some of them are really small, like 2-3 typescript files). It feels like a lot of unnecessary computations.
I feel like typescript should have an option, like "entrypoint" or something. But it seems like "files" and "include" are the only options to play with. It seems like they don't do what I want. I either have to compile the entire directory, or specify the file list by hand. Maybe I am missing something?

[solemn forge]

is include what you're looking for? oh sorry upon reread i see you mentioned include. in what way does it not do what you want?

i'm having trouble visualizing your exact setup. could you perhaps sketch out an example directory hierarchy and show what the relevant config files look like?

[granite bison]

Sure, here it is:

/
├── client
│   ├── index.ts
│   └── utils.ts
├── server
│   ├── index.ts
│   └── utils.ts
└── game-engine
    └── ... whole lot of files

When building the client, I want to compile client and some parts of game engine (related to graphics rendering, networking, etc).
When building the server, I also need the game engine, but in reality only half of its code is actually used, since server does not need such components as graphics, sound, etc.

I could just include the game-engine directory, but it would make typescript compile everything under that directory.
I could enumerate all the directories relevant for both the client and the server, but it would be a ton of work. (and the pain of keeping that enumeration up to date).

It feels like typescript should be able to look at the include tree and only compile the files actually needed for the current bundle. It ends up scrapping the unneeded parts anyways, but it does a lot of work for those. Enough to generate warnings regarging unused code, at least.

@solemn forge

[solemn forge]

typescript knows nothing of bundles. that's all on rollup

is this set up as one big project (i.e. you have a single tsconfig.json)?

seems like it should be split into multiple projects if so

[granite bison]

Well, i can use different tsconfig.json for client and server. Rollup allows that

[solemn forge]

if you need to reference some things across projects you could possibly use project references

[solemn forge]

yeah, this is the way. one tsconfig.json corresponds to one set of outputs

[granite bison]

But i don't really want to enumerate all the files for different bundles

[solemn forge]

not sure what you mean. include and friends support globs

you might not even need to specify include at all if you put the tsconfig files in each of those directories. i think the default value for that option would be what you want

[granite bison]

What i'm trying to achieve is that when you import a file, it automatically gets added to the list of files compiled with typescript.

Is it possible?

[solemn forge]

as in you don't want to write out which projects depend on which other projects (with a setup using project references)?

[granite bison]

I'm currently reading the documentation you sent

[solemn forge]

if so, no i don't think that's something tsc does. that would be configured via rollup or rollup-plugin-typescript, if anywhere

[granite bison]

Didn't hear abour project references before

[granite bison]

Oh, so you mean to separate "client", "server" and "game-engine" in three different projects?

[solemn forge]

yes

[granite bison]

I don't think that'd help, because if "client" requires "game-engine", typescript would compile the entire "game-engine". That's what i'm trying to avoid

[solemn forge]

you can break it down as granularly as you want. like maybe there are 10 projects that live under game-engine

[granite bison]

Oh...

[solemn forge]

also if you do go this route, extends will help you avoid repeating yourself

[granite bison]

Well i could, but i hoped typescript is capable of understanding what's being imported...

[solemn forge]

also FWIW it looks like rollup-plugin-typescript is deprecated and hasn't had an update in 6 years. seems like you should be using @rollup/plugin-typescript instead these days

[solemn forge]

yeah, but typescript is not the thing that knows about concepts like "entrypoints". typescript is only responsible for turning your .ts files into .js files. bundling/entrypoints/etc are rollup concepts. and like i said, maybe there is some way to configure it on that side 🤷

[granite bison]

My bad, i actually use the second one already

just mistyped

[solemn forge]

technical details aside though, it does seem like this is conceptually multiple different projects. like importing from database.ts or whatever in the client project would be a logical error/security concern, right? if so then you might want to separate the projects for reasons other than compilation speed

you could perhaps start by just using three projects: client, server, and game-engine, where client and server both reference game-engine, but do not reference eachother. then only worry about getting more granular than that if the compile time is still too slow for your liking

(also there are a lot of techniques to speed up compile time other than reducing the number of input files)

[granite bison]

I've been developing a few rollup plugins. It computes the entire import tree after running the transform stage. It means typescript transformation should be executed at this point as well.

[solemn forge]

by "transformation" you mean what @rollup/plugin-typescript does?

[granite bison]

I mean typescript -> javascript transformation

[solemn forge]

@rollup/plugin-typescript presumably invokes tslib and/or some other thing to handle that transformation. it could in theory do whatever to prune the set of input files before it does that. i didn't see any obvious options for that in the @rollup/plugin-typescript readme, but i didn't spend much time looking

[glad wagon]

Vite might be of interest. A typical frontend project setup is to separate the type checking and type stripping steps, where you do use tsc but only for type checking, and the bundler simply strip types and does import and bundling stuffs on its own without tsc involved.

[solemn forge]

yeah, decoupling like that is great if your primary concern is reducing time-to-emit

there are also things like @rollup/plugin-sucrase

[granite bison]

I agree on that. See, i'm moving from a different build system. I used to have that functionality and hoped to get it with rollup+typescript.
But you' are right, it would be nice to separate the engine into conceptual parts.

[granite bison]

Any chances it could help?

[solemn forge]

i think it just does type-stripping without checking like what @glad wagon was suggesting you could do via Vite

[granite bison]

Hm, i'll look into that, thank you

[solemn forge]

there's also @rollup/plugin-swc and @rollup/plugin-babel and probably other plugins that would let you achieve a similar workflow

[granite bison]

Yup, my older build system was using babel

[solemn forge]

but Vite is also pretty decent, so do check that out too

[granite bison]

Sure

[solemn forge]

it uses esbuild for dev builds which is generally much faster than rollup

[glad wagon]

Yeah I really recommend taking a look at Vite, it uses Rollup under the hood as well but has it all configured to work out of the box by default, and on top of that you get a dev server with hot reload.

[granite bison]

Thank you! I'll look into that

Excuse me, how do i close a thread here?

Got it

!resolved