publish both cjs and esm version

[gb-jos]

Fixes issue with vite, where mui and tss-react imports different versions of @emotion/react, one being cjs and the other being esm.

[garronej]

Hey @jiby-aurum,
Thanks for the PR!
Unfortunately I can't publish as-is (I have released a beta though) because pepoles import with import {} from "tss-react/mui" in your PR it becomes import {} from "tss-react/dist/<esm | cjs >/mui".
I'm working toward resolving the issue but first I would like to be able to reproduce it.

[gb-jos]

@garronej I can update the pr, such that tss-react/mui is also exported, was not aware this was a public api, I will update the pr in a while

[garronej]

@jiby-aurum in any case, thank you very much for your involvement.
You are greatly helping the project by helping me sort out the this issue.
I am realy surprised no one complained before...

[garronej]

I can reproduce

[garronej]

Don't worry about updating the PR.
I understand now, I'll do it myself now.

[gb-jos]

@garronej perfect!

It should rather be me thanking you for the awesome project, would have been a pain to migrate away from makeStyles to upgrade mui. Thanks a lot for the quick turnaround :)

[garronej]

You are welcome!

Everything is working runtimewise but I still get some red when trying to import the submodule... 🤔

[gb-jos]

@garronej I believe you will have to define the types inside exports for each entry (https://www.typescriptlang.org/docs/handbook/esm-node.html#packagejson-exports-imports-and-self-referencing)

[garronej]

@jiby-aurum you 🪨

[garronej]

I would have bet it would work but it doesn't for some reason 🤔

[garronej]

[gb-jos]

@garronej typescript ‼️ maybe try forcing the resolution via typesVersions (https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#version-selection-with-typesversions), something like

"typesVersions": {
  "*": {
     "*": ["./dist/esm/*"]
  }
},

[gb-jos]

@garronej btw you were correct about assuming it will work, it does work if the consuming project has moduleResolution set to nodenext or node16, seemingly the package.json exports support only in these resolution modes, this was in https://www.typescriptlang.org/docs/handbook/esm-node.html#packagejson-exports-imports-and-self-referencing if you scroll up a bit, I did not notice as well.

but I think it makes more sense with the typesVersions hack as then it works for everyone irrespective of what they have for moduleResolution

[gb-jos]

@garronej just tried 4.1.0-beta.3, works for me perfectly

[gb-jos]

@garronej sadly no, the normal imports complain now 😢

[garronej]

@jiby-aurum I'm still tweeking things

[gb-jos]

@garronej I have a proposal, which is maybe the least friction change from current stable release.

1. we keep the cjs build as it is. (It goes directly into dist and your denoify module copies it to root level)
2. We then build the esm version into an esm folder, (it would go into dist/esm and would be copied to esm folder by denoify)
3. We add just the following to package.json

{
  "module": "dist/esm/index.js",
  "exports": {
    ".": {
      "import": "./dist/esm/index.js",
      "require": "./dist/index.js"
    },
    "./mui": {
      "import": "./dist/esm/mui.js",
      "require": "./dist/mui.js"
    }
  },
}

Im assuming denoify will update all these paths, to remove dist.

I like this for the reasons that

1. We are not touching at all how cjs assets work
2. we don't need any hack for typescript as types are all there in the root

[garronej]

Again thank you for helping me on this, I am strugling.

Im assuming denoify will update all these paths, to remove dist.

You assume correctly yes, gg for figuring that out by yourself.

I like this for the reasons that

Bummer, I was getting hyped, I want to try some more to make it work..
Plus, this feature that I just discovered make me want to do something like:

(it dosen't work though)
(mui.ts and mui_compat.ts as identical runtypewise, juste the types def aren't the same)

It would be so cool not to have to tell users that use older TS version to import the module diferently.

And we still have the problem of the default import not working, still trying to figure out how typesVersions realy works...

[gb-jos]

@garronej I will push my proposal in this branch. And yes typesVersion is just compile time, aka just types

[gb-jos]

@garronej this branch now has my proposal, I tried it locally and it works properly in my project setup

for exports and module I had to put the path without dist as denoify_enable_short_npm_import_path seemingly does not update them

[garronej]

@garronej this branch now has my proposal, I tried it locally and it works properly in my project setup

Thank you!

for exports and module I had to put the path without dist as denoify_enable_short_npm_import_path seemingly does not update them

Yes, I'm updating the script right now.

[garronej]

🤔

[gb-jos]

well, I just copied what was there for the cjs currently, did not really check if these files are generated

[garronej]

Ok but we haven't the types that automatically resolve to compat.d.ts and mui_compat.d.ts with older typescript version...

[garronej]

Does this make sence to you?

I mean do you think i'm on the right path with this?

[gb-jos]

@garronej it makes sense if you want to use the compact types when typescript in consuming project is less than 4.4, but keep in mind that as you mentioned earlier this is only compile time, only the types changes, the implementation won't be the compact ones.

[garronej]

@jiby-aurum Let's forget about using typesVersions to resolve to the compat declaration file for now.
Ama release 4.1.0 thank you again for your help.