-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using Babel for TypeScript instead of tsc #5109
Conversation
Codecov Report
@@ Coverage Diff @@
## next #5109 +/- ##
=========================================
- Coverage 38.3% 37.05% -1.25%
=========================================
Files 649 649
Lines 9853 10181 +328
Branches 388 388
=========================================
- Hits 3774 3773 -1
- Misses 6019 6348 +329
Partials 60 60
Continue to review full report at Codecov.
|
Do we still need a separate |
…l-typescript TODO: need to migrate app/angular/server to TS in order to work with tsc
@Hypnosphi I still need to do a couple of things like renaming files After having some trobules with angular and decorators in general (so no blame on angular except the architectural choice of using decorators 😛 ) @ndelangen and I ended up using babel for js + ts except for angular that now uses I need to think about how to name those files
Maybe we just rename them |
Sounds good to me |
For the record: I had to migrate @storybook/angular in order to be able to compile it with |
# Conflicts: # yarn.lock
# Conflicts: # .babelrc.js # app/angular/src/client/preview/render.js # package.json # yarn.lock
Can you please confirm my changes by using A few tests based on my last commits
|
I can try a couple more things and check the differences between
Initially I wanted to move it to babel to have
|
require.requireActual('core-js/modules/es6.promise'); | ||
// require.requireActual('core-js/es6/reflect'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like you might be able to remove some of this now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ndelangen you changed that, can you take a look at this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should remove if storyshots run successfully without it
@@ -12,10 +12,12 @@ | |||
"strict": true, | |||
"forceConsistentCasingInFileNames": true, | |||
"resolveJsonModule": true, | |||
"isolatedModules": true, | |||
"noEmit": true | |||
"isolatedModules": true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using isolatedModules
in all our tsconfigs could improve tsc performance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we also add declaration: false
here?! I'm not sure what is the best way to make sure this one won't emit any typed files. If we want an emission, then this have to be set to false. See this issue on TS repo here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isolatedModules: true
real 0m18.465s
user 0m0.045s
sys 0m0.045s
isolatedModules: false
real 0m18.345s
user 0m0.030s
sys 0m0.091s
Why should it be faster? What does this option even do? I tried to find more accurate documentation than "exports every file as separate module"
Also keep in mind that this is an example app and depends on the decisions a project owner makes, not storybook.
@ndelangen you added isolatedModules: true
- Were you just playing around with the options or was this on purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it could/should be faster because tsc doesn't need cross-file information to emit. Doesn't look like it makes any difference for us though.
I would still recommend adding it in because it helps enforce rules around "Babel's single file emit architecture". See the caveats section at https://devblogs.microsoft.com/typescript/typescript-and-babel-7/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just found out: TS5053: Option 'declaration' cannot be specified with option 'isolatedModules'.
🐙
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is why I suggest to add declaration: false
together with isolatedModules
, maybe with a comment? In my own project, I have tsc --isolatedModules --noEmit --watch
for type checking, and tsc --declaration --removeComments --emitDeclarationOnly
for type emission. The rest of them goes through babel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm with @leoyli on this one, sounds like that's what we want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm question:
- You start
yarn dev
andyarn dev:tsc
needs to create declaration files for other internal packages that rely on that package: How can I dodeclaration: false
here - You start
yarn bootstrap --core
and internally packages again rely on thed.ts
files of other packages: How can I dodeclaration: false
Is there something I don't get or is this a misunderstanding? 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, yes - it won't fail but at least your IDE will mark those imports red because they are missing - Isn't it confusing if you get red lines in your IDE?
🤔 or are internal packages not red because the IDE can handle this...
@@ -1,12 +1,20 @@ | |||
/* eslint-disable no-console */ | |||
// tslint:disable:no-console |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are log outputs in the compile scripts that are marked red without
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
next PR: replace tslint with eslint everywhere, then it can be removed
Q: Why we want to inject react prop types? For people not using TS or for react-docgen? |
@kroeder Seems like the performance is comparable to This PR:
|
@leoyli I'm not a react user but when I first started the whole typescript migration I had to write types twice:
These can get out of sync so my intention was to get rid of the manually written prop-types |
@kroeder, I can feel your pain... Thank your these great works and your explains. I think it is really questionable on where we need to use prop-types. According to React official doc, it seems that the prop-types is really redundant if we decide to migrate the whole project into TS. But that is out of the scope here... 😓 |
@@ -1,6 +1,6 @@ | |||
const path = require('path'); | |||
import { resolve } from 'path'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mixing es modules & commonjs here, is that recommended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it not recommended? A common linting rule in ts
is no-use-require
or something like that. I can revert that if you want, it works though. I've never experienced any trouble using imports for path like that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
webpack/webpack#4039 (comment)
what about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This post is 2 years old and maybe babel / typescript already converts my import to es5 (can't check right now)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I came across this issue yesterday itself where I was mixing the two. This led to me getting some imports inside default
and some not. Not mixing them up helped me fix it. Although I am not quite sure about your usage.
That's not out of scope, it's our roadmap. But never the less, users of storybook and addon-creators are not all migrating. |
"emitDecoratorMetadata": true, | ||
"experimentalDecorators": true, | ||
"skipLibCheck": true, | ||
"incremental": false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you set incremental build to false
because it is not working with babel for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did that because it failed in a certain scenario.. I think calling yarn bootstrap --core
twice
It should not use a cache here because it removes dist and compiles everything from scratch
I just forgot to add that option for yarn dev
in watch mode
Maybe we can do a tsconfig.prod.json and a tsconfig.json to add transparency in the tsc build process
If it is okay for everyone I'd like to do a feature-freeze for this PR and collect them in an issue for some sort of "Babel refactoring - Phase II" and only fix bugs or change requests that should be done before merging (if we decide to merge 🙂 ) - Is that okay? Currently on the list:
|
this one will have a conflict with my (very small) PR : https://github.com/storybooks/storybook/pull/6415/files Do you think you can make the same change as in mine ? @kroeder |
Let's merge @kroeder ? |
This pull request is automatically deployed with Now. Latest deployment for this branch: https://monorepo-git-ts-migration-babel-typescript.storybook.now.sh |
Congrats @kroeder Epic work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Hypnosphi Mh no I'm not sure but can try to figure this out tomorrow. Does it cause any trouble? |
Not really, just curious |
Issue: #5030
What I did
Using babel as typescript compiler instead of tsc. This allows us to rely on only babel and also gives us the possibility to use a prop-type generator on compile time