-
Notifications
You must be signed in to change notification settings - Fork 64
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
Static Typing with TypeScript (WIP) #619
Conversation
Thanks for the pull request, @bradenmacdonald! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. This is currently a draft pull request. When it is ready for our review and all tests are green, click "Ready for Review", or remove "WIP" from the title, as appropriate. |
fec7712
to
bdea28f
Compare
066be1e
to
27fc161
Compare
27fc161
to
8167a09
Compare
8167a09
to
2e56b14
Compare
Hi @bradenmacdonald! Just checking in on this to see if you're still working on it? |
@mphilbrick211 I ran into some issues and kind of lost the momentum here. I'm going to mark as a draft for now and not sure when I'll be able to revisit it. I would still like to move it forward at some point though. |
I'm going to close this, and open a few smaller PRs with some of the same changes. |
@bradenmacdonald Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future. |
1 similar comment
@bradenmacdonald Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future. |
Description:
This PR incrementally brings static typing and type checking (TypeScript) to
frontend-platform
. See OEP-67-8 TypeScript for some rationale.To achieve this:
// @ts-check
to the top of most.js
files so that TypeScript will check them, and you'll see it in VS Codedist
folder and the existing build step. There's no need for it IMHO. If some MFE that's using this wants to do some kind of Babel transform on its bundle, that can still happen within the MFE build process, but there's no need to do it in advance.typings
folder. This is the new, simplified build step.This should be 100% compatible with existing MFEs that are using this, though they might start seeing type errors if they are using typescript and have some actual errors.
This is also compatible with projects that want to use
"moduleResolution": "Node16", "module": "Node16"
in theirtsconfig.json
, i.e. use theexports
key ofpackage.json
instead of the legacy approach. You can test this by putting"type": "module"
in your MFE'spackage.json
and"moduleResolution": "Node16", "module": "Node16"
intotsconfig.json
compilerOptions
. However, most MFEs seem to be using the legacy CJS approach.TODO:
ConfigDocument
to reflect custom keys unique to each MFE ?Examples from an MFE
These screenshots are from the Course Authoring MFE. You can see that before this PR, VS Code is not aware of the type information of any of the
frontend-platform
functionality. (How do you live like this? :p )intl
andconfig
are bothany
Notice the types of both
intl
andconfig
are now correct.Merge checklist:
frontend-platform
. This can be done by runningnpm start
and opening http://localhost:8080.module.config.js
file infrontend-build
.fix
,feat
) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.Post merge: