[Build] Support module resolution node16 and nodeNext

[RaananW]

To support the new module resolutions (introduced in ts 4.7) we will need to add extensions to the declaration files (just like we are adding to the generated .js files). This might require us to change the repository structure (adding .js to the imports in our libraries), or we will need to parse all generated files and add .js manually.

From initial tests - doing that will not break the current moduleResolution used (i.e. node), so there is no back-compat issue here. This, however, needs to be tested as part of the implementation of this issue.

[github-actions[bot]]

This issue has been automatically staled because it has been inactive for more than 14 days. Please update to "unstale".

[github-actions[bot]]

This issue has been automatically staled because it has been inactive for more than 14 days. Please update to "unstale".

[RaananW]

bumping this up. will tackle this for 8.0

[RaananW]

For future reference - the best solution here, while maintaining back-compat, is to have two sets of types, one in the core directory, and one in ./nodenext/*. The second one has .js in all declarations as well. The way to automate the usage is to add "exports" to package.json:

"exports": {
        "./*":  "./nodenext/*"
    },

What this will do is will force using the new version when using nodenext (or node16 or bundler) as module resolution. Otherwise it will be ignored (as module resolution - node - doesn't use the exports keyword. Sounds a bit off, as one is a ts feature and one is a js feature, but it is really the case...)

Note that when using webpack with nodenext, you will need to add this to config.resolve:

 extensionAlias: {
            ".js": [".js", ".ts"],
            ".jsx": [".jsx", ".tsx"],
        },

Otherwise webpack will not resolve the ts files correctly.

[chase-moskal]

Otherwise webpack will not resolve the ts files correctly.

since my team uses rollup instead of webpack, i don't understand the purpose of this extensionAlias webpack config -- but it prompts me to ask here (regarding this new nodenext distribution):

1. can we expect to use an ordinary out-of-the-box standard modern node resolution just like any other modern package?
2. or will we have to setup some unique config to ingest babylon?

of course, i'm hoping it's the first option😅

as a potentially-related side note -- babylon's reliance on side-effects is constantly hurting us, as we often have to do a bunch of debugging on a random error, and it basically takes a stroke of luck to realize that it's because we're missing some module's necessary side-effect -- i thought that there was once a roadmap item to have this fixed, but i can't seem to find it anymore -- i just wonder if addressing this problem could be a consideration that might be related to this module work? -- if it cannot be fixed, maybe we could start mapping and documenting all the modules that require side effects, and all the modules that provide side effects, to make the process of hunting down the necessary relationships much easier.. just let me know if it would be useful for me to create a separate issue about this.

thanks for all your hard work, we really appreciate it, it makes our soon-to-be-announced open source game project possible ❤️

[RaananW]

I will do whatever in my powers to never make it option 2. This is the reason behind technically compiling the framework twice, one for nodenext and one for node. This way everyone gets a version of the framework that will be consumed automatically.

Now, regarding side effects - I never hid my opinion about the need to ditch side effects. There is a small issue with doing that in regards to our current package architecture, because this will cause some breaking changes to people using the es6 packages already. We are constantly finding new smart ways of solving this and evaluating them. When we find the best way we will deliver a side-effect-free version of the framework.

[github-actions[bot]]

This issue has been automatically staled because it has been inactive for more than 14 days. Please update to "unstale".