Closed etrepum closed 1 week ago
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
lexical | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Apr 18, 2024 8:19pm |
lexical-playground | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Apr 18, 2024 8:19pm |
When the tests fail it looks like this:
Hi! Shouldn't it be possible for the compiler to simply bundle shared/*
files? This is what tsup
does for example..
I guess proper hotfix here is to rollback #5831 and do patch release
The compiler is creating the shared files in .ts-temp/shared but in order for them to be useful they would need to be copied somewhere inside the packages that depend on them and then the imports would need to be rewritten to use relative rather than absolute paths (e.g. ./_shared/x
instead of shared/x
). I am not aware of any options to the typescript compiler to get it to do what we want for this situation, I think we do need to bring in a build tool like api-extractor or maybe tsup to do this for us (short of doing something bespoke).
The compiler is creating the shared files in .ts-temp/shared but in order for them to be useful they would need to be copied somewhere inside the packages that depend on them and then the imports would need to be rewritten to use relative rather than absolute paths (e.g.
./_shared/x
instead ofshared/x
). I am not aware of any options to the typescript compiler to get it to do what we want for this situation, I think we do need to bring in a build tool like api-extractor or maybe tsup to do this for us (short of doing something bespoke).
You're right. tsc
can't do this. I would propose to replace it with proper type declarations bundler.
https://github.com/microsoft/TypeScript/issues/4433 presents some good ideas on how one might accomplish that with community-maintained tools, including API Extractor, rollup-plugin-dts, and tsup.
So instead of trying to rush suboptimal solution here - rollback & switch to one of the better options instead.
But I don't have a strong position here if someone wants to merge it.
Update here. So tsup
works kinda out of the box here... Just do:
# Install tsup for monorepo
$ cd packages/lexical-utils
$ npx tsup ./src/index.ts --dts-only
# Profit!
I can probably fix it later on. Or @etrepum you can do it. How:
I could switch the build script to use tsup in #5876 instead of calling tsc, looks like it will be fairly straightforward. I think either way it makes sense to have the sanity check that I added in the second commit https://github.com/facebook/lexical/pull/5920/commits/bae93d3a90101165c79a3e40de5448a89f42f81b
tsup is a bit slower than I expected, each package takes maybe two seconds to process (and they all have to be handled separately due to the way tsup works, doing it in-process doesn't seem to change much).
I think the output is mostly ok, but there are some unintended consequences:
declare global {
interface Document {
documentMode?: unknown;
}
interface Window {
MSStream?: unknown;
}
}
@etrepum I'll take a look later today/Monday. Thanks for the input!
@StyleT here is a branch that uses tsup and fixes the problems I noticed, but I should do some more validation to make sure it's not missing anything else before bringing it in to #5876 https://github.com/etrepum/lexical/tree/tsup-build
Short summary here:
tsup
doesn't work well because:
esnext
target w/o ability to override it https://github.com/egoist/tsup/blob/00188a0dc848c48fac45de245d1e021f370a84a3/src/rollup.ts#L147dts-bundle-generator
is painfully slow and requires excessive configuration as it doesn't works same was as tsc
api-extractor
fails to figure out types for vars where we do destruction (known issue)rollup-plugin-ts
requires rollup 3.x+ and has same issues as tsup
except last oneSo this solution seems optimal
dts-bundle-generator is painfully slow
@StyleT how can I reproduce this issue? Happy to take a look into and hopefully fix it.
requires excessive configuration as it doesn't works same was as tsc
Also would like to know more about this issue, if you have time.
Thanks!
Quick hotfix to re-export the shared/* constants with an explicit
export const X: boolean = X_;
(where the original constant is imported renamed asX_
). This ensures that TypeScript's output does not include any imports to the source ofX_
.I'm not sure if there's a better way to get typescript to inline types from private modules, but I wanted to get this hotfix out to fix the regression introduced by #5831. I had time to do a bit more research and add a validation step so that this doesn't happen again. It seems that a more ergonomic solution to this class of problems would be to use api-extractor (#5921).
fixes #5918