question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Proposal: Port to TypeScript

See original GitHub issue

Hello @paldepind, as I know you’re aware, we are making use of this fantastic library in Cycle.js and Motorcycle.js has been using it since about November or December. We’ve been more and more embracing TypeScript and find that the only thing that is difficult is libraries which we are dependent on, not having or having out-of-date typings, which is why I had sent a PR for type definitions previously. However maintaining type-definitions is tedious, painfully error-prone, and now I have many spread across multiple projects that I try my best to keep up-to-date, but has been difficult.

I’ve been working on reviving some neglected parts of Motorcycle, porting to TypeScript, and I’ve been doing my best to ensure that all packages are tree-shaking compatible providing ES2015 builds alongside the commonjs builds. This is where I’ve ran into issues.

Compiling a TypeScript library/application to ES2015 does not allow for commonjs module.exports (Technically exports.prop will not work either, but there are workarounds). For type definitions to be correct, they use the following syntax

declare namespace "snabbdom/h" {
  export = // ...
}

Which restricts TypeScript to using import h = require('snabbdom/h') but this disallows compiling to ES2015, and thus disallows tree-shaking compatibility.

So I propose moving the current codebase, starting with a 1:1 port, to TypeScript. Type Definitions will be consistent 100% of the time for users, and are properly versioned with snabbdom itself. Other benefits include ES2015 builds for tree shaking and standards compliance. Another benefit, if tests are written in TypeScript, typings can also be tested.

I would more than happily do this work myself and submit it as a PR, if this is desired.

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:16
  • Comments:8 (8 by maintainers)

github_iconTop GitHub Comments

5reactions
TylorScommented, Aug 18, 2016

Sooo, I went ahead and did this work as I mentioned I would, but for the moment its in a separate repo. All of the same tests are passing, and performance within the vdom-benchmark (100 iterations) are not too far from the current codebase (I know these tests arent very definitive), which is better than I expected to be honest. I had much less faith in the compiled output. I tested the commonjs builds of course, there could be a difference in the ES2015 output since there is less difference between TS and ES6.

snabbom-ts

https://github.com/TylorS/snabbdom-ts https://travis-ci.org/TylorS/snabbdom-ts

For those curious I cloned the vdom-benchmark-snabbdom from https://github.com/vdom-benchmark and simply changed the dependencies.

I did as much as I could to be backwards compatible with the current version but a few things are technically breaking changes. TypeScript does not like the current thunk() implementation as it allows for staying backwards compatible with 0.4.x so the signature enforces the use of a key. The only other thing that is different is when using require()

const h = require('snabbdom/h').default

I’m not too interested in maintaining a virtual-dom library as you’ve already created one that suits all of my needs, so I hope I can take this work and merge it back into mainline if all things are acceptable.

3reactions
paldepindcommented, Aug 18, 2016

I like TypeScript so I think a port is a splendid idea! 👍

I think we should just change the API of thunk as discussed in #143. Making it compatible with TypeScript is yet another benefit.

If you’re interested I can create a branch for the TypeScript port and give you commit access?

Btw, one thing I’d like to get done before porting is merging @katyo’s rewrite of the event listeners module. I just need to properly review the PR.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Documentation - Migrating from JavaScript - TypeScript
Converting a JavaScript codebase over to TypeScript is, while somewhat tedious, usually not challenging. In this tutorial, we're going to look at how...
Read more >
Proposal: Convert to TypeScript #76 - pact-foundation/pact-js
Removing the old type declarations; Port latest karma examples (a62d00f and 93cba30); Add in type checks / guards for common native JS scenarios...
Read more >
How to move your project to TypeScript - at your own pace
Learn how you can move your existing JavaScript project, step by step to TypeScript. All at your own pace and as much as...
Read more >
How to Migrate a React App to TypeScript - SitePoint
Learn how to migrate a React app to TypeScript from JavaScript, and take advantage of type safety for more reliable code.
Read more >
Porting JavaScript (or TypeScript) to AssemblyScript | Fastly
First, let's figure out what we want to port. ... AssemblyScript does offer a global Date object; however, it works by importing the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found