Change Request: Stop rolling up package #374
Description
Environment
HEAD
What problem do you want to solve?
Right now, we're rolling up the files in this package for distribution, we requires us cleaning up duplicate type definitions. This is a lot of work and we're stuck with how we can reference types between files due to these limitations.
What do you think is the correct solution?
Stop rolling up the package. This isn't strictly necessary because it's an ESM-only package, and therefore, we're not getting much extra value from rolling things up.
We can remove Rollup and just have tsc emit both types and code to the dist directory. The end result for plugin users will be the same and it will allow us more flexibility with how we import and define types.
Participation
- I am willing to submit a pull request for this change.
Additional comments
No response
Metadata
Metadata
Assignees
Type
Projects
Status
Milestone
Relationships
Participants
Activity
xbinaryx commentedon May 13, 2025
I'll look into this if there is consensus within the team.
lumirlumir commentedon May 14, 2025
I believe this issue aligns with the one I’ve been working on: #367.
While the combination of
rollupanddudupe-typesis nice, but it introduces unnecessary complexity when working with types.If this is accepted, it will make the ongoing migration to the
@importsyntax (#367) much easier.So, 👍 to this! Let’s move forward.
But one thing I’m afraid of is: wouldn’t this be a breaking change?
nzakas commentedon May 14, 2025
I don't think so. What is it you think would break?
lumirlumir commentedon May 15, 2025
I'm just wondering —
If we remove
rollupand rely only ontscemit, is it still possible to put all type declarations into a single file likeindex.d.ts, as we did before?Does the automatically generated
index.d.tsfile emitted bytscinclude all type information like before?nzakas commentedon May 15, 2025
When doing this with
tsc, it will generate anindex.d.tsfile to go along with theindex.jsfile. There will also be.d.tsfiles for each individual file, andindex.d.tswill import the other.d.tsfiles as needed.For a package user, this change is transparent.
lumirlumir commentedon May 16, 2025
Thank you for the explanation.
In that case, I suppose there won’t be any issues if we stop bundling the packages. 👍
fasttime commentedon May 20, 2025
Sounds good to remove the Rollup bundling step to simplify the build process. +1 from me.
mdjermanovic commentedon May 20, 2025
Sounds good to me too 👍
snitin315 commentedon May 20, 2025
Marking this as accepted. @xbinaryx Would you like to send a PR?
tats-u commentedon Jun 4, 2025
How about tsup, tsdown, or rslib?
lumirlumir commentedon Jun 4, 2025
@tats-u Thanks for your suggestion. — Just to clarify, though, this is more about removing the bundling system from the build process entirely, rather than migrating to a different one 😄
tats-u commentedon Jun 5, 2025
tsdown and rslib can generate .d.ts more quickly than tsc by omitting type check.
I think you want to do a type check when generating dts and only tsc is fine.
We can adopt the Go-powered tsc in the future if you feel tsc is too slow.
nzakas commentedon Jun 5, 2025
@tats-u performance isn't a consideration here. This script runs only when the package is built during a release.