fix: migrate build tools to tsdown
This PR aims to replace the main packages build tool from vite lib mode -> tsdown:
- core
- cientos
- postprocessing
Closes #1211
Deploy Preview for tresjs-docs ready!
| Name | Link |
|---|---|
| Latest commit | 775df275935d5f5415e51dc82990c9b2ffb140da |
| Latest deploy log | https://app.netlify.com/projects/tresjs-docs/deploys/691cad8dcd961f0008cc7df1 |
| Deploy Preview | https://deploy-preview-1215--tresjs-docs.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify project configuration.
Deploy Preview for tresjs-lab failed. Why did it fail? →
| Name | Link |
|---|---|
| Latest commit | 5b06cc1dfd078b5810095116231f78ef495b617c |
| Latest deploy log | https://app.netlify.com/projects/tresjs-lab/deploys/69043f6923f0f50008f2a160 |
@tresjs/cientos
npm i https://pkg.pr.new/@tresjs/cientos@1215
@tresjs/core
npm i https://pkg.pr.new/@tresjs/core@1215
@tresjs/eslint-config
npm i https://pkg.pr.new/@tresjs/eslint-config@1215
@tresjs/leches
npm i https://pkg.pr.new/@tresjs/leches@1215
@tresjs/nuxt
npm i https://pkg.pr.new/@tresjs/nuxt@1215
@tresjs/post-processing
npm i https://pkg.pr.new/@tresjs/post-processing@1215
commit: 775df27
Just a note: latest rolldown version will be able to treeshake json files; in our case, TresCanvas.vue using the package.json to add the version (current version with all the package.json in the SFC); when rolldown updated, the package.json from the sfc should just use the version from the package.json
I tried pkg.pr.new release in my local project, and it threw errors
Error: Error during dependency optimization:
Build failed with 1 error:
[plugin vite:dep-pre-bundle]
Error: Package subpath './webgpu' is not defined by "exports" in C:\Projects\vue-demo\node_modules\three\package.json
at async EnvironmentPluginContainer.resolveId
my three.js has to be pinned in v162 so I fixed it in https://github.com/Tresjs/tres/pull/1212/files#diff-ae67801fb224ca1be3bb245fa54bddc7c74638162eec2eca946f924a892b26d5
I don't think webgpu support was available on v162
I know that WebGPURenderer is first introduced in v167, but according to https://github.com/Tresjs/tres/blob/011a8a55bd099c140c9865b25022791f79f3da95/packages/cientos/package.json#L58 we can not break apps using v133~v166 three.js, it actually works in 5.1.0, that's why I fixed this in https://github.com/Tresjs/tres/pull/1212 or check
renderer.isWebGPURenderer === true
WDYT?
Deploy Preview for tresjs-lab ready!
| Name | Link |
|---|---|
| Latest commit | 775df275935d5f5415e51dc82990c9b2ffb140da |
| Latest deploy log | https://app.netlify.com/projects/tresjs-lab/deploys/691cad8d9081f10008ef6a08 |
| Deploy Preview | https://deploy-preview-1215--tresjs-lab.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify project configuration.
We still need:
- remove all
@tresjs/**used from npm registry: there are some packages using a version (5.0.0/5.1.0) insteadworkspace:* - review
postprocessingpackage:@tresjs/coreas peer => I think it should be a dependency. - migrate
lechespackage build to tsdown - try to inject package version using define instead importing the full package: iirc rolldown will treeshake unsed entries soon (maybe not required): will require also a tsdown update
- fix nuxt playgrounds (review tsconfig and maybe adding the fix added here https://github.com/Tresjs/tres/pull/1215/commits/f047df8081eb1b64757d170a895b09f957f8c900)
- review subpackages exports are fine (removing
exports: truefromtsdownconfig files), maybe we need to addattwcheck
Hi @userquin
remove all @tresjs/** used from npm registry: there are some packages using a version (5.0.0/5.1.0) instead workspace:*
I added the workspace:* to the legacy cientos playground, which will be merged into the apps/playground soonish. The rest are peer dependencies 0947816
review postprocessing package: @tresjs/core as peer => I think it should be a dependency.
Why do you think it should be a dependency? @tresjs/core is intentionally a peer dependency because @tresjs/postprocessing is an extension package, not a standalone
If core were a regular dependency, users could end up with multiple versions of threejs installe,d which is a common issue. The peer dependency ensures they share a single core instance with compatible versions. Check https://github.com/pmndrs/react-postprocessing/blob/90d10d59fe5a1a86e027c1bedd36dcf3b87ddd1c/package.json#L62-L65
migrate leches package build to tsdown
Yeah, I exclude this package from the migration since I depend on the vite-plugin-css-injected-by-js to inject the CSS. If you know how to do it with tsdown, we can explore it in another PR.
try to inject package version using define instead of importing the full package: iirc rolldown will treeshake unused entries soon (maybe not required): will require also a tsdown update
I guess the optimization would be technically correct, but the bundle impact is minimal, and if rolldown will soon handle that then it is a marginal benefit.
@userquin seems that with we fixed the nuxt generate issue but now the build has a memory leak. I test it on an external project with pkg.pr.new and it doesnt have the issue
ℹ ✓ built in 7.61s 11:24:50 AM
✔ Server built in 8009ms 11:24:50 AM
ℹ Initializing prerenderer nitro 11:24:50 AM
<--- Last few GCs --->
[12619:0x8d5400000] 278502 ms: Mark-Compact 4038.9 (4135.5) -> 4037.9 (4135.3) MB, pooled: 0 MB, 2766.42 / 0.00 ms (average mu = 0.428, current mu = 0.395) allocation failure; scavenge might not succeed
[12619:0x8d5400000] 286158 ms: Mark-Compact 4053.6 (4135.3) -> 4052.9 (4167.0) MB, pooled: 0 MB, 7273.79 / 0.00 ms (average mu = 0.196, current mu = 0.050) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0x102e199b4 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/usr/local/bin/node]
2: 0x102fe805c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/local/bin/node]
3: 0x1031f7784 v8::internal::Heap::stack() [/usr/local/bin/node]
4: 0x1031f5b24 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
5: 0x1031ea10c v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
6: 0x1031ea944 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
7: 0x1031beaf0 v8::internal::FactoryBase<v8::internal::Factory>::NewRawOneByteString(int, v8::internal::AllocationType) [/usr/local/bin/node]
8: 0x1031cf538 v8::internal::Factory::NewStringFromUtf8(v8::base::Vector<unsigned char const>, unibrow::Utf8Variant, v8::internal::AllocationType) [/usr/local/bin/node]
9: 0x103004b04 v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [/usr/local/bin/node]
10: 0x102f44c6c node::StringBytes::Encode(v8::Isolate*, char const*, unsigned long, node::encoding, v8::Local<v8::Value>*) [/usr/local/bin/node]
11: 0x102d5b188 node::encoding_binding::BindingData::DecodeUTF8(v8::FunctionCallbackInfo<v8::Value> const&) [/usr/local/bin/node]
12: 0x103a170f4 Builtins_CallApiCallbackOptimizedNoProfiling [/usr/local/bin/node]
13: 0x10f4626d4
14: 0x10ee31e68
15: 0x11002a278
16: 0x103a11dc8 construct_stub_create_deopt_addr [/usr/local/bin/node]
17: 0x11002a52c
18: 0x11002bb5c
19: 0x10e9fb0dc
20: 0x103b1c4d8 Builtins_PromiseFulfillReactionJob [/usr/local/bin/node]
21: 0x103a41594 Builtins_RunMicrotasks [/usr/local/bin/node]
22: 0x103a12af4 Builtins_JSRunMicrotasksEntry [/usr/local/bin/node]
23: 0x10314f640 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/usr/local/bin/node]
24: 0x10314fee8 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/usr/local/bin/node]
25: 0x103150020 v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*) [/usr/local/bin/node]
26: 0x10317d244 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/usr/local/bin/node]
27: 0x10317d9c8 v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) [/usr/local/bin/node]
28: 0x102d199a8 node::InternalCallbackScope::Close() [/usr/local/bin/node]
29: 0x102d19474 node::InternalCallbackScope::~InternalCallbackScope() [/usr/local/bin/node]
30: 0x102e1d95c node::fs::FileHandle::CloseReq::Resolve() [/usr/local/bin/node]
31: 0x102e37df4 node::fs::FileHandle::ClosePromise()::$_0::__invoke(uv_fs_s*) [/usr/local/bin/node]
32: 0x102e118b0 node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/usr/local/bin/node]
33: 0x1039ef300 uv__work_done [/usr/local/bin/node]
34: 0x1039f2db0 uv__async_io [/usr/local/bin/node]
35: 0x103a065c4 uv__io_poll [/usr/local/bin/node]
36: 0x1039f3318 uv_run [/usr/local/bin/node]
37: 0x102d1a4f4 node::SpinEventLoopInternal(node::Environment*) [/usr/local/bin/node]
38: 0x102e62a7c node::NodeMainInstance::Run() [/usr/local/bin/node]
39: 0x102dd4a80 node::Start(int, char**) [/usr/local/bin/node]
40: 0x191c29d54 start [/usr/lib/dyld]
If we have peer dependencies for tresjs we should define all tresjs at root (and maybe inside resolutions) since pnpm can link them to npm registry instead workspace, we need to check any peer inside any workspace here resolving to the workspace.
If you try to add the resolution inside the workspace package.json pnpm will complain.
Maybe nx can help on this?
About the memory heap error (maybe a memory leak or maybe it is huge), where is the error? If the error when buiding apps/docs or apps/lib we need more memory or reduce parallelism (not sure how to do that with nuxt, I reported a few years ago an issue when building iconify icons website). We also have some issue about memory at vueuse, it is also huge.
If we have peer dependencies for tresjs we should define all tresjs at root (and maybe inside resolutions) since pnpm can link them to npm registry instead workspace, we need to check any peer inside any workspace here resolving to the workspace.
If you try to add the resolution inside the workspace package.json pnpm will complain.
Maybe nx can help on this?
@userquin So I checked whether this issue is actually present in our monorepo by running pnpm why @tresjs/core across different packages. I also checked the .pnpm virtual stores, and there are no npm-installed versions, only symlinks, since the workspace: is also present on the devDependencies. I get that the overrides are a best practice for more complex dep graphs, but it would be solving a problem that doesn't currently exist in our setup. If we see that is an issue in the future, we can revisit it.
Why do you think it should be a dependency?
Because some entries using tresjs core iirc, will check it again. We need to check if tsdown inlining tres core (similar issue we have at main with threejs)
NOTE: leches and cleanup will go to another PR respetively (we also need to add auto-import/unimport stuff)