support NodeNext module resolution

[bbohlender]

The placement of the *.d.ts files currently prevents support for projects that use the NodeNext module resolution since the .d.ts are expected to be placed with their definitions. Additionally, the .js file ending is expected. The changes in this PR should enable both the current node moduleResolution and the NodeNext moduleResolution.

[jeetiss]

@cc-bbohlender could you please remove this line from build.js
https://github.com/shuding/yoga-wasm-web/blob/main/build.js#L44

it doesn't do anything because you commit d.ts files to the repository

[jeetiss]

@cc-bbohlender I'm sorry for the delay

is it will work with yoga's wrapAsm.d.ts? Do we need to change imports in this file too?

https://github.com/facebook/yoga/blob/main/javascript/src_js/wrapAsm.d.ts#L24-L26

[bbohlender]

@jeetiss No worries. Thanks for your time :)

I have access to the enums since they are exported here:

yoga-wasm-web/dist/index.d.ts

Line 3 in e9141ef

export * from "./generated/YGEnums.js";

However, it would be best if yoga's types included the .js file extension.

I can make a PR there too, if you think it's reasonable, they will accept it. There is additionally a problem with the unsetMeasureFun <-- missing a c
https://github.com/facebook/yoga/blob/220d2582c94517b59d1c36f1c2faf5e3f88306f1/javascript/src_js/wrapAsm.d.ts#L159

[jeetiss]

There is additionally a problem with the unsetMeasureFun <-- missing a c

Nice catch, this should be a PR definitely :)

[bbohlender]

Okay, thanks, will do.

Do you happen to know why yoga exports the constants on the yoga object?
https://github.com/facebook/yoga/blob/220d2582c94517b59d1c36f1c2faf5e3f88306f1/javascript/src_js/wrapAsm.js#L149

Because the yoga-wasm-web types express that the constants are exported

yoga-wasm-web/index.d.ts

Line 3 in eac8026

export * from "./dist/generated/YGEnums";

But the actual implementation does not export them

yoga-wasm-web/index.js

Line 3 in eac8026

Resulting in no compile error from typescript but a runtime error for:

import { UNIT_AUTO } from "yoga-wasm-web"

yoga-wasm-web does not provide an export named 'UNIT_AUTO'

I would at least export the constants here:

yoga-wasm-web/index.js

Line 3 in eac8026

but I then also, I see no reason to put them on the yoga object
https://github.com/facebook/yoga/blob/220d2582c94517b59d1c36f1c2faf5e3f88306f1/javascript/src_js/wrapAsm.js#L149

[jeetiss]

This is a nice catch too.

this is happening because we initialize wasm differently how original yoga does. i think that we should reuse the original yoga as much as possible so we can migrate when it will be released (i hope it will be some time)

I'm going to export constants too as in the original yoga package

https://github.com/facebook/yoga/blob/main/javascript/src_js/entrypoint/_entryAsync.js#L14
https://github.com/facebook/yoga/tree/main/javascript#usage

[jeetiss]

Seems like this is not so easy to do because esbuild can't reexport commonjs imports

[bbohlender]

Yeah, I see. I guess, we have to wait until yoga changes the js code to es6 modules.
The constants could be exported as Constants, but for my use case in particular, I don't need them.

However, I would then at least remove the export to prohibit confusion from here:

yoga-wasm-web/index.d.ts

Line 3 in eac8026

export * from "./dist/generated/YGEnums";

I will now continue to make the PR on yoga to use the file extensions and include the typo fix. Depending on how fast that PR goes through, the current PR here, is also valuable for me without the enums from yoga.

[jeetiss]

@cc-bbohlender thanks for your contribution! 🎉

I have some ideas on how we can modify d.ts files from the yoga repo to support NodeNext. But it will be nice to have tests. Do you have any experience in writing tests for types? i'm not ;) I saw that vitest have added support for testing types https://vitest.dev/api/expect-typeof.html

[bbohlender]

@jeetiss After reading the comment from the yoga PR, I see a problem.
facebook/yoga#1228

They are not using the "type" field in their package.json, which defaults to "commonjs". The yoga-wasm-web package uses "type": "module". I guess this is to enable "yoga-wasm-web/asm" import instead of "yoga-wasm-web/dist/asm". However, since yoga-wasm-web uses the files from the yoga repo, their interpretation differs since the "type" field in both use cases differs.

The hard way would be to write declaration files that can be interpreted as "module" and "commonjs" or to try and transition the yoga repo to also use "module".

However, the simplest solution I see is to change this package to "commonjs" and flatten the dist folder in the distribution so that "yoga-wasm-web/asm" can still be imported.

Since "commonjs" packages can be used in NodeNext, this would also make this PR obsolete.
However, I am unsure if other reasons require the "type": "module" field. I am sorry that this solution comes to my mind so late.

[jeetiss]

write declaration files that can be interpreted as "module" and "commonjs"

I don't understand why we should support "commonjs" here, because this fork is in esm (rollup converts all commonjs files from yoga repo into esm), so as I understand from TS docs we need to convert the d.ts files to esm compatible format to. Am I right?

change this package to "commonjs"

I prefer to keep this package as "module"

[bbohlender]

From the yoga repo, there is no reason to change the file extensions in the .d.ts files, since everything works fine even with NodeNext since their package type is "commonjs". Since this package has type "module", the .d.ts files must include the file extensions to support NodeNext.
Maybe there is a tool that can automatically add the file extensions, or we write own code to do that, or we include own typings into the repo, which would then diverge from the yoga repo.