Open chigix opened 1 year ago
Interesting proposal.
I think we would want to continue to maintain the type declarations in the Moddable SDK. We could synchronize those to the DefinitelyTyped repository periodically. Would that achieve your goals?
I'd be interested to hear the opinions of other developers using TypeScript regularly, such as @meganetaaan, @HipsterBrown, and @cmidgley.
Programming Moddable can have a normal practice to leverage the NPM package ecosystem.
This feels like a separate topic.
I agree that it would be great for Moddable to embrace NPM and DefinitelyTyped (I already use NPM for all my Moddable work, though it wasn't a simple task). However, I think the elephant in the room is that Moddable doesn't yet truly embrace TypeScript. Many interfaces are not yet defined with types, and new modules and interfaces continue to become available without types being available - often leaving the definition as a project for the community.
My preference would be to see Moddable truly embrace a "TypeScript first" methodology - even to the point of writing all new modules in TypeScript - and use TSC to compile the JS version for those users who do not wish to use TypeScript (similar to how much of the NPM world works). It's great having Moddable support .d.ts
files (and they have been instrumental for me, so no complaints here as Moddable is fantastic), but they are a crutch in the TypeScript world and will always be "extra work" to maintain as interfaces evolve. Native TS would make that entire issue go away... Of course, that is no small task and is really a cultural debate in the end (especially as it relates to embedded).
If that were to happen, then DefinitelyTyped and NPM make sense as a logical next step.
My two cents...
+1 on @cmidgley's comment
I'm not a fan at all of having to "program types" and I'm not a fan of TypeScript's complexity (I understand why it is what it is). However, if I'm trying to write reliable software I personally face three options: (1) do a ton of manual testing, (2) write lots of tests, or (3) use TypeScript. (Of course these are not mutually exclusive.) I have found that (1) simply doesn't happen and that I'm not good at (2) especially at maintaining the tests that invariably seem to be 10x longer than the code itself. So I've started to try option (3).
My experience so far is that "TypeScript in moderation" is quite palatable and does help avoid many mistakes that would take a lot of test cases to uncover. By "in moderation" I mean that I resort to any
et. al. when things get too hairy and I don't see the benefit of spending an hour working out some crazy typing stuff.
WRT npm I'm a bit stumped. It seems to me that some of the fundamental ways it handles dependencies just don't jibe with embedded systems. I mean, I normally don't like to have two versions of some package loaded but in a moddable project I really, really wouldn't want that. I also find that many packages have a lot of cruft and all I do is pluck out that one .js file I actually want/need (and then copy in the appropriate license header). Or is the idea to use npm but only really install from a "moddable universe of packages", similar to how Node-RED uses the convention to prefix packages with "node-red-"? Can someone perhaps lay out pros and cons of using npm and perhaps some experience?
I agree with @phoddie that the types should be colocated with the source code as long as the Moddable team chooses to own them. The DefinitelyTyped repo is for a community to provide types when the package authors don't or won't; which does not match the intent of this project IMHO.
As a developer who uses TypeScript at work and in most of my personal projects, I've seen the benefits the language can provide when maintaining larger codebases and safely executing updates. However, it does need to be embraced by the maintainers in order to garner those benefits, and it adds additional complexity to the distribution of the SDK compared to the current setup.
I've discussed with the Moddable team in the past, but this repo currently serves multiple purposes: build tooling, SDK, and library / integration registry. Pulling these strings apart in order to publish the SDK as a package will be a tough process, but worth the effort to be a part of the JS ecosystem in some way. These are clear expectations from the community, which might conflict with how it is currently used by teams shipping products today. Whether or not the package is published to npm, homebrew, apt, or just as part of the standard GitHub release is really a side-effect of the first step. Once that step is taken, then it becomes clearer how to generate and include types from Moddable.
I'm happy to help with this work in whatever way I can be of assistance.
Third-party dependency management has been an open feature issue for xs-dev
since nearly the beginning: https://github.com/HipsterBrown/xs-dev/issues/49
I'm interested in feedback from folks who have gotten projects set up with Moddable & npm.
Thank you all for the thoughtful input and apologies for my delay in replying.
My hope is that there are some concrete steps we can take to continue to improve the experience of developers using TypeScript with the Moddable SDK. I'm not one of those developers on a day-to-day basis (as @cmidgley points out), but I do use it from time-to-time and understand the appeal. My limited experience means I'm not confident about deciding what to do next. Some consensus from developers who do use TypeScript regularly is essential.
I like @tve's perspective of "TypeScript in moderation." It echos good advice @bmeck gave me about TypeScript (in fact, Bradley was our first TypeScript contributor!).
I understand that TypeScript developers would be pleased if we were to embrace TypeScript for implementation of core modules. That will be something of a cultural debate though, and I don't think we're close to that. TypeScript developers love TypeScript. There are also more than a few JavaScript developers who really don't. Developers should have that choice. Typings literally provide an interface between those worlds, so I think we should keep the focus there for the moment.
I recognize that it is frustrating to TypeScript developers when we add a new API but without the corresponding typings file. We should fix that. That said, creating typings files can be challenging so I'm not sure the Moddable team can or should do that alone. Maybe that's a starting point for @HipsterBrown's restructuring thoughts.
There's a bunch of topics mixed together here. Maybe we could try having a real-time discussion? The next Moddable Community Call is this Thursday morning (9 AM California time). @HipsterBrown and I will already be there. @tve was there last month. We could talk after the formal agenda (which shouldn't be more than 15 minutes).
Describe Extending the practice with Visual Studio Code introduced in the page: https://blog.moddable.com/blog/typescript/ Would it be possible to request further support to support the practice of a normal npm package as a normal TypeScript Project programming?
Proposal
@types/moddable
that can be retrieved from npm directly.package.json
file in this repository root.node_modules
.Why do you think this feature would be useful?
Why do you think this feature would be useful? I can draft a pull request for migrating the types files in the current repository towards TypeScript's
@type
repository -- DefinitelyTyped.