What should I start doing?

[skilbjo]

I am a little broken... your project saved my sanity tonight (thank you very much) but I am worried that I am doing something wrong by having to use it ... can you document your motivations for the project and advice to ensure node compatibility going forward ?

Here is my rant ...
Transforming our codebase and internal libs from cjs -> esm was HORRIBLE and NOT WORTH IT. But what's done is done and the projects are using esm now. I had to use --experimental-specifier-resolution=node on node18 to get things running without doing more surgery on the project.

However when it came to bumping to node20, I found out unexpectedly that flag (--experimental-specifier-resolution) 1) is now a no-op and 2) not even a warning is emitted when using that flag anymore! WTF. And the suggested workaround in the docs is a lib that doesn't work. THANK YOU for creating this project and saving me from either 1) emergency unexpected work or 2) downgrading back to node18

Question is what should I be doing to get more conformity ... ie should I start migrating over to the .js extensions ? Any tsconfig.json changes that need to be paired with that ? I do use deep imports (import * as subPkg from '@skilbjo/pkg/dist/sub-package') - am I screwed and should I start changing that. And if so, advice would you give if I have a "monorepo" internal library with segmented file trees -- ie @skilbjo/monolib/cdk vs @skilbjo/monolib/sdk/ (where I would normally import as import * as cdk from '@skilbjo/monolib/cdk and import * as sdk from @skilbjo/monolib/sdk - is that the point of exports in package.json?

What other advice do you give to move to """modern""" / the-direction-node-is-pointing-towards JS ?

[skilbjo]

I've just come across your stack overflow post

[barhun]

I am a little broken... your project saved my sanity tonight (thank you very much) but I am worried that I am doing something wrong by having to use it ... can you document your motivations for the project and advice to ensure node compatibility going forward ?

You're welcome! I did this for my own sanity, but it's nice to know it also helps others keep theirs too! (: I've, so far, tried to keep it compatible with newer versions of node in the same week they were released and I intend to do the same with future releases. When I initially published this package to the npm repository, the highest node version was v19; and now, thanks to those minor changes, we're still good with the latest which is, for the time being, v21.

Here is my rant ... Transforming our codebase and internal libs from cjs -> esm was HORRIBLE and NOT WORTH IT. But what's done is done and the projects are using esm now. I had to use --experimental-specifier-resolution=node on node18 to get things running without doing more surgery on the project.

I think you did the right thing moving forward with ESM; even though there remain some discrepancies and confusion around the topic, it's the future and all major JS engines/runtimes do now encourage their users to move in that direction as well.

However when it came to bumping to node20, I found out unexpectedly that flag (--experimental-specifier-resolution) 1) is now a no-op and 2) not even a warning is emitted when using that flag anymore! WTF. And the suggested workaround in the docs is a lib that doesn't work. THANK YOU for creating this project and saving me from either 1) emergency unexpected work or 2) downgrading back to node18

Question is what should I be doing to get more conformity ... ie should I start migrating over to the .js extensions ? Any tsconfig.json changes that need to be paired with that ? I do use deep imports (import * as subPkg from '@skilbjo/pkg/dist/sub-package') - am I screwed and should I start changing that. And if so, advice would you give if I have a "monorepo" internal library with segmented file trees -- ie @skilbjo/monolib/cdk vs @skilbjo/monolib/sdk/ (where I would normally import as import * as cdk from '@skilbjo/monolib/cdk and import * as sdk from @skilbjo/monolib/sdk - is that the point of exports in package.json?

No, I think you should just stick to the ESM resolution with extensionless specifiers and make no unnecessary changes to your project in this context. Bun does have out-of-box support for it enabled by default while node and deno do not, but I guess they'll (re)implement it in the future and offer the same experience as Bun.

What other advice do you give to move to """modern""" / the-direction-node-is-pointing-towards JS ?

I have no say in the direction node is taking, so I cannot tell you anything about that.

[skilbjo]

class. ty very much @barhun