Open richardo2016 opened 2 years ago
@richardo2016 thank you for the suggestions! yes, totally, we're currently considering different options transitioning LSF to TypeScript or at least providing a decent .d.ts
declarations. This is something we definitely want to deliver. Unfortunately, I can't currently give you any estimations on when it will happen as the codebase is pretty massive, and any approach we take on it will require time to implement.
This is the process our team used to adopt Typescript, and it worked well:
tsconfig.json
file). You guys have already done this :heavy_check_mark:LabelStudio
class including all its arguments, and will add the most initial value to those consuming this package..ts
and .js
files can be mixed in a project, so you don't have to migrate to Typescript all at once. Instead, during normal development activity, you can ask anyone who makes an edit to a .js
file to also convert it to a .ts
file and add types to it.Hey all!
Thank you, @epeters3 for adding your tips to this! It's super appreciated!
I know this is a conversation that the community has been enthusiastic about and I've heard it from the community lens as well ā so just adding the Community Label and getting myself set up for alerts to keep in touch with updates. :)
Definitely appreciate the input and appreciate the transparency from @nicholasrq. š
@richardo2016 thank you for the suggestions! yes, totally, we're currently considering different options transitioning LSF to TypeScript or at least providing a decent
.d.ts
declarations. This is something we definitely want to deliver. Unfortunately, I can't currently give you any estimations on when it will happen as the codebase is pretty massive, and any approach we take on it will require time to implement.
I'm glad your team is considering these suggestions! In addition to my gratitude, please allow me to offer some of my own insights.
When you mentioned "considering different options transitioning LSF to TypeScript," I believe this indicates that your team "will take some measures to provide types with minimal changes to the existing code." In my opinion, the best way to achieve this is actually to rewrite the existing JS/JSX files in TypeScript. The remaining issues can be solved using TypeScript's complete toolchain.
I do not recommend to "providing a decent .d.ts declarations." I have seen many JS frameworks and libraries do this, and it can work for smaller libraries with stable external interfaces. However, for a project like LFS, which constantly changes component behavior and external interfaces as the business evolves, writing a separate *.d.ts
file in addition to writing JS code is a heavy burden. Moreover, once a team abandons synchronizing the interface definitions of JS code with *.d.ts for the sake of iteration speed, it actually creates bigger problems for the users: the official generated types/interfaces are incorrect.
I do not recommend to "providing a decent .d.ts declarations." I have seen many JS frameworks and libraries do this, and it can work for smaller libraries with stable external interfaces. However, for a project like LFS, which constantly changes component behavior and external interfaces as the business evolves, writing a separate
*.d.ts
file in addition to writing JS code is a heavy burden. Moreover, once a team abandons synchronizing the interface definitions of JS code with *.d.ts for the sake of iteration speed, it actually creates bigger problems for the users: the official generated types/interfaces are incorrect.
I agree with this approach, and although new components are written in typescript the main entry point for lsf should be prioritized to include definitions that can help both dev's looking to integrate as well as those working to transition the existing code base. It feels like an achievable and bite size first step that will pay big dividends.
nicholasrq what would it take to get this prioritized?
When might this be prioritized?
Hi : )
I am one frontend engineer, I used to build web app such label-studio-frontend WITH TypeScript/Javascript. I found label-studio is a grateful & useful annotation tool for my friend who works on AI, he/she needs to label/annotate data to prepare data for his/her training model.
Like some projects I seeked or wrote for them, the frontend of label-studio is not driven by TypeScript, so its customer could not benefit from its Type system. if you install
@heartexlabs/label-studio
and import it to your existed project, no any Type Hints for frontend engineer.Maybe, I think, we should introduce Typescript into label-studio now, reasons below:
In 2022, more and more frontend projects are built with Typescript, most frontend engineers have been used to it and want explicit type hints when they import one new npm package to their project --- even though their own project isn't driven by Typescript, they can still benifit from IDE's TS Server support (e.g. VS Code)
On the early stage of label-studio, maybe some full-stack engineers can develop both backend and frontend of label-studio. But as your project/product label-studio become biggier and more complex, and you want to sell the commercial version to your customer, they maybe need to tell their frontend engineer: "embed label-studio into our products". But, We all know the fact: most frontend engineers don't know how AI engineer works, what AI engineer needs. So the frontend engineer needs to read your document, to learn the domaintic knowledge and the conception in label-studio first, then he/she could embed label-studio gratefully.
But, if label-studio provides type support in npm package, most frontend engineers could benifit from it: they maybe know less about annotation/label, but the property exported const types, function signature would help them know what capability label-studio provides, with the example in documentation, they would embed it into an existed project faster.