Typescriptify Webpack

Webpack has been incredibly popular around the JS world. Its design philosophy wins trustment of the community.

To further envolvement, it’s very important that webpack has solid codebase to embrace the rapidly changing world.

However, as code grows, without great test suite and other devtool, code can be gross. For now, webpack’s source is written in ES5. And as you know, there isn’t much documentation in the source. It’s hard for incoming contributors to understand the codebase. Thus, it’s harder to make webpack real-better.

Typescript is a great tool to help webpack to achieve greater goal.

SO, you can see https://github.com/ts-webpack/webpack/tree/feature/tsify is out!


Current status of ts-webpack

done

  • the core dependency tree of webpack have been converted into typescript mostly(except watchpack).

  • types of those sorrounding modules have been submitted to DefinintelyTyped. This is for more accurate type checking for webpack eventually.

  • the source code of webpack has been converted into typescript catching up with the recent commits(needs further synchronization)

  • its fully compatibility with current test suite. (There is one bug of the latest typescript which will causes test error)

missing

  • enable strictNullChecks and make the source fully type-checked.

  • a new set of build-tool to support and guard the new source code.

  • refactoring to make some code more clear to be understood.

  • adopt ES6 module system to fix the reference error as some module’s structure is incompatitble with the type system(at least for now there is no easy way to solve that).

  • responses from the webpack core-team and the community 😄

Author: Fantashit

8 thoughts on “Typescriptify Webpack

  1. Then once we drop node .12 support we can then start merging those changes in and start a class by class file by file transition. I think once this is accomplished we can then start exploring the possibilities with TS or Flow there are benefits to either that we should heavily weigh before deciding.

  2. First of all: thx @e-cloud for that suggestion and your tremendous work. I don’t really see how many parts of webpack you’ve already translated but it was surely already a lot of work. I really appreciate that 👍

    Personally, I’m not Anti-TypeScript and I totally see the benefits of defining types for other developers (for auto-completion and validation for instance), but I see a huge trade-off in terms of accessibility for other developers. We’ve seen this problem already with CoffeeScript, although I must admit that TS is closer to JS than CS was.

    If we want to improve the developer experience (and I agree with you in regards to the current code base), I think Flow would be a more lightweight approach, where we have type checking but without actually using another language. But I have no practical experience with Flow so I’m a little bit clueless here.

    That being said: I’m not totally against this, but I’m not convinced that the benefits outweigh the effort.

  3. @jhnns My 2 cents: TypeScript is as much “type checking but without actually using another language” as flow. IMHO there is practically not a big difference in terms of usage between them. They only differ slightly in some details about typings or code analysis. I also think flow is as much a “different language” to JavaScript as TypeScript is. They are just JavaScript with types. In flow you have to add /* @flow */ on top of your files to (initially) start type checking, in TypeScript you would rename your .js file to .ts. I wouldn’t say this makes TypeScript more of a different language.

    Yes, not all valid JavaScript code is valid TypeScript code. But as far as I can see only error prone code is rejected – which I think is a good thing.

    I think neither flow nor TypeScript can be compared to CoffeeScript here. In my experience flow/TypeScript is not a “huge trade-off in terms of accessibility”, but can help others accessing your code a lot, because the types help people explain your code and they help navigating inside your project.

    But it’s true that flow can be more “lightweight” to add and use, if you already have a Babel-based build pipeline in place.

    Comparing both flow and TypeScript, I don’t prefer any solution really much in points of features, but I slightly prefer TypeScript a little bit more, because in my experience there are a little bit more popular, so you find more typings of 3rd party code, its community supports more different frameworks (flow is most popular in the React community) and tooling in IDEs is better (thanks to TypeScripts great language server).

  4. current status

    For the last days, I’ve been adding typings for the source and sync with the upstream repo.
    Most of source code have been typed. What’s left is to adjust unmatched types, and to enable strictNullCheck and then fix improper types.

    about bugs

    And in that period, with Typescript’s check, I’ve found out several dead code and a bunch of bugs. Some small bugs are small enough to fix out during the typing work. The other are left to discuss and then have fixes.

    Ad again

    In current typescriptified webpack source, there are not much advanced Typescript features used. That’s to say, if the team are willing to change, the migration should be less painful and easy to maintain and envolve. The Typescript features used now are nothing more than ES6 + basic type system( and a little ES7 ). IMHO, it’s the same when using ES6(not 5) + Flow.

    I can announce, with Typescript, the quality of source will be much more solid. 😌

  5. Would still like to see it 👍 It would help me when I use the Node API of webpack (especially for prereleases or stuff like that, which is usually don’t covered by @types/webpack).

  6. Oct 15, 2016

    Support for taking the time to convert the entire project to TypeScript. We believe that TypeScript allows users to better write scaled and complex code with rich APIs (like webpack). If we can make code easier for you to write, then its worth our time to invest in for your contributions.

    Apr 20, 2018

    We have talked about this at length in many threads and if it really is needed we can provide a document. The short of it is we do not want anything except JavaScript.

    What changed? 😕

    If you really don’t want the goodness that is TypeScript, then you might as well close this issue.

  7. @TheLarkInn @sokra With more projects (including jest) moving towards Typescript, is there any reconsideration of this position? I could not find the document promised in this comment that would explain the rationale.

    I don’t necessarily work in webpack much, but I do work on plugins and loaders against the API, and even @TheLarkInn has mentioned how bad the DefinitelyTyped definitions for webpack are. However, if webpack were in Typescript, then it could emit authoritative typings that are updated with every version.

Comments are closed.