Add downlevel dts master

[lychyi]

Issue: Fixes #9463, an alternative to #9826

While there are incompatible declaration outputs between TypeScript 3.7+ and TS3.5, there is a workaround to use the latest TypeScript version while still maintaining compatible d.ts files. This is accomplished by using downlevel-dts to generate alternative typings for users on a certain version of TypeScript.

In this PR, any users who are on TS3.5 and below, TypeScript will automatically look at the package.json for a field called typesVersions and utilize the typings in that folder via a mapping.

  "typesVersions": {
    "<=3.5": { "*": ["ts3.5/*"] }
  },

What I did

I modified the compile-tsc.js script to use downlevel-dts and generate typings from the dist folder to a ts3.5/dist folder. Then I added the above snippet to each package.json with a corresponding types field. I'm assuming other package.jsons without types are not actually exporting any TypeScript files.

Refer to the comments in #9463 for more detail.

How to test

I tested it by manually altering node_modules with this output in @storybook/channels inside my own project that suffers from #9463. The project indeeds builds correctly now with TypeScript 3.5.3 and Storybook 5.3.12.

I also verified that the folder lib/channels/ts3.5/dist/index.d.ts has this line:

readonly hasTransport: boolean;

instead of

get hasTransport(): boolean;

I'd probably like a second set of eyes on it to make sure it works and also help out on any automated tests(if we think it's worth the effort).

[gaetanmaisse]

You have updated package.json of all libs and addons, I think we need to do the same for all /apps packages that are written in TS.

[gaetanmaisse]

@lychyi Thanks for this PR 😍 great work! 👍
We just need to discuss the output folder #9847 (comment) ;)

[shilman]

Y'all are so on top of this stuff. Great work!!! 🙇🙇🙇

[lychyi]

@gaetanmaisse Good points, I just followed the example on downlevel-dts so I had to think about it for a sec. This was the most compelling reason I could think of:

ts3.5/dist is essentially mirroring whatever was in dist in another location. If we do dist/ts3.5, in the very low chance that someone names a src folder ts3.5 you'll essentially clobber what's in there when you compile and downlevel TS into dist. So the downside in this case is that ts3.5 becomes a reserved folder name that you can't use, it's not a deal breaker but it's just a mental nugget that you have to keep in mind.

And yes, good call on the files attribute 😅... and setting typesVersions for app/. I did a find and replace for the "types: " attribute in package.json files and I'm baffled how I missed that.

It probably is worth it to say though, I'll defer to the maintainers because that's the biggest impact as a result of this question. I don't have a strong preference.

[gaetanmaisse]

@ndelangen @kroeder what do you think about downlevel-dts' output folder ⬆️ #9847 (comment) and #9847 (comment)?

[lychyi]

✏️ Just writing down a mental note here ✏️

This PR still may need the files attribute altered in package.json before merging. I'll do it once the decision is made about where we downlevel things to.

[lychyi]

@gaetanmaisse files attribute has been updated.

Note: I added this to every package.json that specifies that it ships *.d.ts in files even though the package may not have d.ts files to ship. I'm still debating if this is the right call but I figured if we're specifying that it could ship d.ts files in the future, we would need to ship downleveled types too so I made it consistent across the project so we don't have to account for it in the future.

For example, if someone wants to create a new package, do they copy and paste from an existing package.json or is there a script that generates one? If it's the former, then having it in every package.json would make sense.

Maintainers: feel free to modify the PR if that wasn't the right call or I can do it as soon as you let me know.

[gaetanmaisse]

@lychyi LGTM! I just added a commit with some typesVersions you missed. Or was it intentional?

Tested locally:

• Reproduce TS1086: An accessor cannot be declared in an ambient context #9463
• Use packages of this branch with yarn link
• Everything was 🟢

@shilman @ndelangen don't know if someone else wants to take a look 👨🏻‍💻 If not, I think it can be merged, what's the process, merge on master and then master is merged in next? or merged on next and then cherry-picked on master?

[ndelangen]

@gaetanmaisse This PR targets master, so let's merge this to master first

I'm unsure if cherry-picking this is easier then creating an additional PR against next?

[lychyi]

@gaetanmaisse Ah, I think I wrongly assumed that only packages with the types attribute shipped typings to downlevel. Good call on this.

[gaetanmaisse]

@lychyi I think it was a valid assumption but there are suspicious things with these packages I will take a look at them 🔍🕵

[gaetanmaisse]

@lychyi Thanks for your work 🎉 🎉 🙇

I will cherry-pick and create the PR for next ASAP.

[lychyi]

🎉Thanks for the assist! ❤️ Lovin' the project and are more than happy to help. @gaetanmaisse @ndelangen @shilman

[shilman]

@lychyi @gaetanmaisse @ndelangen I just realized that this was merged into master and the second PR is going into next! 🙀

I just released the second PR as part of https://github.com/storybookjs/storybook/releases/tag/v6.0.0-alpha.14

Since this feels like a biggish change, can you please QA that release a bit and let me know if it looks good? Once I get your go-ahead, I'll release this change on 5.3.x.

Thanks!! 🙏🙏🙏

[gaetanmaisse]

🛑 It looks like there is a bug with Addon Centered because it's the only package that export types from "root" dir. Here is the fix: #9907 ⚠️ I targeted next

Everything else looks good.