build: bundle dts via api-extractor and move deps to dev only#1293
build: bundle dts via api-extractor and move deps to dev only#1293
Conversation
2dc011e to
19ed32d
Compare
19ed32d to
d307480
Compare
d307480 to
cb48d0a
Compare
cb48d0a to
a7bb7b5
Compare
| resolved "https://registry.yarnpkg.com/@types/webxr/-/webxr-0.5.0.tgz#aae1cef3210d88fd4204f8c33385a0bbc4da07c9" | ||
| integrity sha512-IUMDPSXnYIbEO2IereEFcgcqfDREOgmbGqtrMpVPpACTU6pltYLwHgVkrnYv0XhWEcjio9sYEfIEzgn3c7nDqA== | ||
| version "0.5.5" | ||
| resolved "https://registry.yarnpkg.com/@types/webxr/-/webxr-0.5.5.tgz#9e0a27e809c8f76cc1ef525d9f96b8fd94ef9c42" |
There was a problem hiding this comment.
modified to contain this fix DefinitelyTyped/DefinitelyTyped@b2505fd
|
fdb0c87 addressed missing import issues. The added exports are most for building the dts bundle. |
|
the report files end with |
| import { removeUnnecessaryVertices } from './removeUnnecessaryVertices'; | ||
| import { rotateVRM0 } from './rotateVRM0'; | ||
|
|
||
| export type { deepDispose, removeUnnecessaryJoints, removeUnnecessaryVertices, rotateVRM0 }; |
There was a problem hiding this comment.
mhm,,, How does it work? If I understand that the api-extractor simply forgets to output types for such static members, is that correct?
There was a problem hiding this comment.
I added these to avoid api-extractor generating dts with some missing types. But after trying again now the issue has not been fixed. 🤔 Let me check it again.
There was a problem hiding this comment.
Ah, I think I finally figured this out.
three-vrmis exportingVRMExpressionLoaderPluginformthree-vrm-corewhich usetypes-vrm-0.0inside- if we bundle
three-vrm-corewithtypes-vrm-0.0first, some exports fromtypes-vrm-0.0became private inthree-vrm-corebut it works fine - if we bundle
three-vrmwith bundledthree-vrm-corethen, the private part is untouchable fromthree-vrmso the output dts is incomplete- which seems reasonable so it's hard to say it's a bug in
api-extractor
- which seems reasonable so it's hard to say it's a bug in
The same thing happends to ConstraintSchema.
So our options are
- do not bundle dts from
types-*packages in intermediate packagesthree-vrm-*and only bundle them insidethree-vrm- can achieve single dts and no deps install
- some exports from
types-*are still private so maybe hard to use - types may conflict to user installed
types-* - introduce inconstancy
- treat all
types-*as dependencies or peerdependencies and let user install them- not true dts bundle but flexible
- option to not install
types-vrm-0.0at all
- re-export or provide a public interface for each
types-*inthree-vrm-*- can achieve single dts and no deps install
- needs dependency design?
What do you think?
There was a problem hiding this comment.
Sounds like 2 is the best option...? It sounds easier from a contributor perspective at least.
3 is probably the most favorable option from a user perspective but it would make the module hard to maintain.
| export * from '@pixiv/three-vrm-springbone'; | ||
|
|
||
| export type { VRMMaterialsV0CompatPlugin } from '@pixiv/three-vrm-materials-v0compat'; | ||
| export type { VRMNodeConstraintLoaderPlugin } from '@pixiv/three-vrm-node-constraint'; |
There was a problem hiding this comment.
Doesn't it overwrapped with the line export * from '@pixiv/three-vrm-node-constraint'; ?
| export * from '@pixiv/three-vrm-node-constraint'; | ||
| export * from '@pixiv/three-vrm-springbone'; | ||
|
|
||
| export type { VRMMaterialsV0CompatPlugin } from '@pixiv/three-vrm-materials-v0compat'; |
There was a problem hiding this comment.
I think we can simply expose the entirety of @pixiv/three-vrm-node-constraint since it's already included in the build regardless.
As post as cons: may be noisy / pollute search results |
ooo that actually sounds sweet. While I slightly feel that I want to try this, by looking at other adopters no one is using this feature. Would you want to recommend us using the feature? |
| import type * as V0VRM from '@pixiv/types-vrm-0.0'; | ||
| export type { V0VRM }; |
There was a problem hiding this comment.
If I understand correctly, these two lines are needed to control whether we are going to expose V0VRM from three-vrm-core or not, right?
Why we need to have this in src/expressions/index.ts , not src/index.ts ?
abe7da1 to
136ce08
Compare
136ce08 to
f0c66b6
Compare
close #1289
OPTIONS:
@microsoft/api-extractorrollup-plugin-dts@microsoft/api-extractortorollup-plugin-dtsfrom after 3.3do not bundle at all
Needs discussion: