Skip to content
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

Update Blockly codebase to Typescript #5857

Closed
38 of 47 tasks
rachel-fenichel opened this issue Jan 7, 2022 · 11 comments
Closed
38 of 47 tasks

Update Blockly codebase to Typescript #5857

rachel-fenichel opened this issue Jan 7, 2022 · 11 comments
Assignees
Labels
internal External contributions not accepted

Comments

@rachel-fenichel
Copy link
Collaborator

rachel-fenichel commented Jan 7, 2022

Steps for this update. These are not necessarily in order, and some will be broken out as separate bugs.

Old Tracking List:

Must happen pre merge:

  • Check all @enums for formatting issues. [beka]
    • Fix KeyCodes in core/utils/keycodes.ts. [christopher]
  • Check all @typedefs for lost JSDocs. [beka]
  • Export @typedefs that were static properties on classes [beka]
  • Move comments that migrants put in the wrong place [beka]
  • Remove remaining declareLegacyNamespace calls [christopher]
  • Migrate blockly.js to blockly.ts [christopher]
  • Get Blockly to pass CI. [TBD]

Can happen post merge:

  • Fix any @protected properties that have been changed to parameter properties [beka]
  • Check that public parameter properties are correct [beka]
  • Investigate why compose is commented out in BlockSvg [beka]
  • Export interface types that were exported from blockly.js [beka]
  • Redefine properties that were defined using Object.defineProperties [christopher]
    • Check that we've properly deprecated all of the above properties, including any in blocks or generators. [beka]
  • Find new places to put the properties that were defined using Object.defineProperties [beka]
  • Implement piping sourcemaps from tsc to closure compiler [christopher]
  • Get generating type defs working [beka]
    • Rename instances of AnyDuringMigration in defs to any[beka]
  • Fix packaging sources (.ts instead of .js) [beka]
  • Get API Extractor Working
    • Get Maribeth set up with a branch that builds [beka]
    • Enable API Extractor. [maribeth]
    • Migrate JSDoc to TSDoc. [TBD]
      • Move any docs attached to property assignments to property definitions [TBD]
    • Figure out how to pipe the results of API Extractor to devsite [maribeth]
  • Update the Blockly style guide to document where we differ from the Google TS (or JS) styleguide
    • E.g., using TSDoc, requiring blank line before @params, listing all @params even when annotation adds no information, etc.
  • Update the renamings script to handle the new import structure for blocks and generators [beka]
  • Fix BlocklyOptions (which stopped actually defining anything during the goog.module migration) [beka]
  • Make block.workspace not nullable [aaron]
  • Add type information to interfaces [aaron]

Optional niceties:

  • Deal with IRegistrableField trying to include a static property in an interface We were actually doing this correctly.
  • Remove unused JSDoc attributes
  • Get ESLint to work with Typescript [maribeth]
  • Fix CSS formatting. E.g. common/constants [beka]
  • Look into DynamicShape in common/constants [beka]
  • Update everything to conform to the ts styleguide
  • Remove all instances of AnyDuringMigration [beka/aaron]
  • Revert changes to the BlockDefinition type (in /blocks) Update BlockDefinition type import in block definition files #6248

Additional portions of the Blockly codebase (outside of core/ to migrate:

@rachel-fenichel rachel-fenichel added issue: triage Issues awaiting triage by a Blockly team member internal External contributions not accepted labels Jan 7, 2022
@daniel-brenot
Copy link

I've been experimenting with this in my fork. I've deleted a large portion of the project structure for the moment and renamed all of the js files to ts. If you would like to work with me on this i am more than happy to accept help.

Most of the work i've been doing is using tools i'm making myself to do some simple find and replaces, although some syntax tree parsing seems to now be in order to handle things such converting the prototypes to classes, so that's my current focus. The branch i am currently on is mostly to see how far i can get with this and then once it is done i will create a new branch that i will squash the changes that are needed onto without having the messy history involved in the experimentation.

Feel free to contact me and check out my branch

@rachel-fenichel
Copy link
Collaborator Author

@daniel-brenot sure, can you send me a link to the relevant branch on your fork?

I've been working through the ES6 classes part: #5860 and associated pull requests. I've been using a tool to do the class conversions, then touching it up as needed. Some classes can't be converted yet, often because we're not calling super at the beginning of the constructor.

After class conversions the most critical thing is to get the build process working.

@daniel-brenot
Copy link

I'm looking into lebab for the automatic conversion. I'm experementing with multiple ways of doing most of the work automatically since the repository is so large.

My branch can be found here: https://github.com/daniel-brenot/blockly

@daniel-brenot
Copy link

Part of this is that it may be prudent to separate some of the work for blockly into separate repositories for things such as generators for different languages.

@rachel-fenichel
Copy link
Collaborator Author

Separate repositories, or just separate issues for tracking each piece of work?

The swap to Typescript tooling will not involve making separate repositories, because that expands the scope of the work well past a quarter.

In the future we want to move generators, block definitions, and some other files out of core and into plugins, but we need to have clear migration paths for developers and generally minimize disruption where possible.

@daniel-brenot
Copy link

Makes sense. In my local version i'm going to try to make typescript compile each one of the separate parts into a separate file with separate definitions to keep it compatible with how it seems to currently be done.

@BeksOmega
Copy link
Collaborator

BeksOmega commented Jun 28, 2022

I'm moving the task tracking here. [Edit: Moved into the top level comment]

@tolst0v
Copy link

tolst0v commented Jul 13, 2022

coolconsole.log('cool')

@cpcallen cpcallen mentioned this issue Aug 31, 2022
4 tasks
@BeksOmega BeksOmega added this to the 2022_q3_release milestone Sep 27, 2022
@BeksOmega BeksOmega removed their assignment Apr 12, 2023
@BeksOmega
Copy link
Collaborator

I'm going to close this because it looks like we haven't been using it for task tracking in over a year.

@itsezc
Copy link

itsezc commented May 30, 2024

I'm going to close this because it looks like we haven't been using it for task tracking in over a year.

Where is the tracking happening currently? Would love to stay up to date with the progress.

@BeksOmega
Copy link
Collaborator

I'm going to close this because it looks like we haven't been using it for task tracking in over a year.

Where is the tracking happening currently? Would love to stay up to date with the progress.

I don't think any work is currently being done to convert more things to typescript. All of the external-facing code (I.e. everything but tests) has already been converted. Although we do have a few issues open for improving what we've got:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal External contributions not accepted
Projects
None yet
Development

No branches or pull requests

7 participants