1 | # Sucrase
|
2 |
|
3 | [![Build Status](https://travis-ci.org/alangpierce/sucrase.svg?branch=master)](https://travis-ci.org/alangpierce/sucrase)
|
4 | [![npm version](https://img.shields.io/npm/v/sucrase.svg)](https://www.npmjs.com/package/sucrase)
|
5 | [![Install Size](https://packagephobia.now.sh/badge?p=sucrase)](https://packagephobia.now.sh/result?p=sucrase)
|
6 | [![MIT License](https://img.shields.io/npm/l/express.svg?maxAge=2592000)](LICENSE)
|
7 | [![Join the chat at https://gitter.im/sucrasejs](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/sucrasejs/Lobby)
|
8 |
|
9 | ### [Try it out](https://sucrase.io)
|
10 |
|
11 | Sucrase is an alternative to Babel that allows super-fast development builds.
|
12 | Instead of compiling a large range of JS features down to ES5, Sucrase assumes
|
13 | that you're targeting a modern JS runtime (e.g. Node.js 8 or latest Chrome) and
|
14 | focuses on compiling non-standard language extensions: JSX, TypeScript, and
|
15 | Flow. Because of this smaller scope, Sucrase can get away with an architecture
|
16 | that is much more performant but less extensible and maintainable. Sucrase's
|
17 | parser is forked from Babel's parser (so Sucrase is indebted to Babel and
|
18 | wouldn't be possible without it) and trims it down to focus on a small subset of
|
19 | what Babel solves. If it fits your use case, hopefully Sucrase can speed up your
|
20 | development experience!
|
21 |
|
22 | **Current state:** The project is in active development. It is about 20x faster
|
23 | than Babel and about 8x faster than TypeScript, and it has been tested on
|
24 | hundreds of thousands of lines of code. Still, you may find correctness issues
|
25 | when running on a large codebase. Feel free to file issues!
|
26 |
|
27 | Sucrase can build the following codebases with all tests passing:
|
28 | * Sucrase itself (6K lines of code excluding Babel parser fork, typescript,
|
29 | imports).
|
30 | * The [Benchling](https://benchling.com/) frontend codebase
|
31 | (500K lines of code, JSX, typescript, imports).
|
32 | * [Babel](https://github.com/babel/babel) (63K lines of code, flow, imports).
|
33 | * [React](https://github.com/facebook/react) (86K lines of code, JSX, flow,
|
34 | imports).
|
35 | * [TSLint](https://github.com/palantir/tslint) (20K lines of code, typescript,
|
36 | imports).
|
37 | * [Apollo client](https://github.com/apollographql/apollo-client) (34K lines of
|
38 | code, typescript, imports)
|
39 | * [decaffeinate](https://github.com/decaffeinate/decaffeinate) and its
|
40 | sub-projects [decaffeinate-parser](https://github.com/decaffeinate/decaffeinate-parser)
|
41 | and [coffee-lex](https://github.com/decaffeinate/coffee-lex)
|
42 | (38K lines of code, typescript, imports).
|
43 |
|
44 | ## Transforms
|
45 |
|
46 | The main configuration option in Sucrase is an array of transform names. There
|
47 | are four main transforms that you may want to enable:
|
48 | * **jsx**: Transforms JSX syntax to `React.createElement`, e.g. `<div a={b} />`
|
49 | becomes `React.createElement('div', {a: b})`. Behaves like Babel 7's
|
50 | [babel-preset-react](https://github.com/babel/babel/tree/master/packages/babel-preset-react),
|
51 | including adding `createReactClass` display names and JSX context information.
|
52 | * **typescript**: Compiles TypeScript code to JavaScript, removing type
|
53 | annotations and handling features like enums. Does not check types.
|
54 | * **flow**: Removes Flow type annotations. Does not check types.
|
55 | * **imports**: Transforms ES Modules (`import`/`export`) to CommonJS
|
56 | (`require`/`module.exports`) using the same approach as Babel 6 and TypeScript
|
57 | with `--esModuleInterop`. Also includes dynamic `import`.
|
58 |
|
59 | The following proposed JS features are built-in and always transformed:
|
60 | * [Class fields](https://github.com/tc39/proposal-class-fields): `class C { x = 1; }`.
|
61 | This includes static fields but not the `#x` private field syntax.
|
62 | * [Export namespace syntax](https://github.com/tc39/proposal-export-ns-from):
|
63 | `export * as a from 'a';`
|
64 | * [Numeric separators](https://github.com/tc39/proposal-numeric-separator):
|
65 | `const n = 1_234;`
|
66 | * [Optional catch binding](https://github.com/tc39/proposal-optional-catch-binding):
|
67 | `try { doThing(); } catch { }`.
|
68 |
|
69 | ### JSX Options
|
70 | Like Babel, Sucrase compiles JSX to React functions by default, but can be
|
71 | configured for any JSX use case.
|
72 | * **jsxPragma**: Element creation function, defaults to `React.createElement`.
|
73 | * **jsxFragmentPragma**: Fragment component, defaults to `React.Fragment`.
|
74 |
|
75 | ### Legacy CommonJS interop
|
76 | Two legacy modes can be used with the `import` tranform:
|
77 | * **enableLegacyTypeScriptModuleInterop**: Use the default TypeScript approach
|
78 | to CommonJS interop instead of assuming that TypeScript's `--esModuleInterop`
|
79 | flag is enabled. For example, if a CJS module exports a function, legacy
|
80 | TypeScript interop requires you to write `import * as add from './add';`,
|
81 | while Babel, Webpack, Node.js, and TypeScript with `--esModuleInterop` require
|
82 | you to write `import add from './add';`. As mentioned in the
|
83 | [docs](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#support-for-import-d-from-cjs-form-commonjs-modules-with---esmoduleinterop),
|
84 | the TypeScript team recommends you always use `--esModuleInterop`.
|
85 | * **enableLegacyBabel5ModuleInterop**: Use the Babel 5 approach to CommonJS
|
86 | interop, so that you can run `require('./MyModule')` instead of
|
87 | `require('./MyModule').default`. Analogous to
|
88 | [babel-plugin-add-module-exports](https://github.com/59naga/babel-plugin-add-module-exports).
|
89 |
|
90 | ## Usage
|
91 |
|
92 | Installation:
|
93 |
|
94 | ```
|
95 | yarn add --dev sucrase # Or npm install --save-dev sucrase
|
96 | ```
|
97 |
|
98 | Run on a directory:
|
99 |
|
100 | ```
|
101 | sucrase ./srcDir -d ./outDir --transforms typescript,imports
|
102 | ```
|
103 |
|
104 | Register a require hook with some [reasonable defaults](src/register.ts):
|
105 |
|
106 | ```js
|
107 | // Register just one extension.
|
108 | import "sucrase/register/ts";
|
109 | // Or register all at once.
|
110 | import "sucrase/register";
|
111 | ```
|
112 |
|
113 | Call from JS directly:
|
114 |
|
115 | ```js
|
116 | import {transform} from "sucrase";
|
117 | const compiledCode = transform(code, {transforms: ["typescript", "imports"]}).code;
|
118 | ```
|
119 |
|
120 | There are also integrations for
|
121 | [Webpack](https://github.com/alangpierce/sucrase/tree/master/integrations/webpack-loader),
|
122 | [Gulp](https://github.com/alangpierce/sucrase/tree/master/integrations/gulp-plugin),
|
123 | [Jest](https://github.com/alangpierce/sucrase/tree/master/integrations/jest-plugin) and
|
124 | [Rollup](https://github.com/rollup/rollup-plugin-sucrase).
|
125 |
|
126 | ## What Sucrase is not
|
127 |
|
128 | Sucrase is intended to be useful for the most common cases, but it does not aim
|
129 | to have nearly the scope and versatility of Babel. Some specific examples:
|
130 |
|
131 | * Sucrase does not check your code for errors. Sucrase's contract is that if you
|
132 | give it valid code, it will produce valid JS code. If you give it invalid
|
133 | code, it might produce invalid code, it might produce valid code, or it might
|
134 | give an error. Always use Sucrase with a linter or typechecker, which is more
|
135 | suited for error-checking.
|
136 | * Sucrase is not pluginizable. With the current architecture, transforms need to
|
137 | be explicitly written to cooperate with each other, so each additional
|
138 | transform takes significant extra work.
|
139 | * Sucrase is not good for prototyping language extensions and upcoming language
|
140 | features. Its faster architecture makes new transforms more difficult to write
|
141 | and more fragile.
|
142 | * Sucrase will never produce code for old browsers like IE. Compiling code down
|
143 | to ES5 is much more complicated than any transformations that Sucrase needs to
|
144 | do.
|
145 | * Sucrase is hesitant to implement upcoming JS features, although some of them
|
146 | make sense to implement for pragmatic reasons. Its main focus is on language
|
147 | extensions (JSX, TypeScript, Flow) that will never be supported by JS
|
148 | runtimes.
|
149 | * Like Babel, Sucrase is not a typechecker, and must process each file in
|
150 | isolation. For example, TypeScript `const enum`s are treated as regular
|
151 | `enum`s rather than inlining across files.
|
152 | * You should think carefully before using Sucrase in production. Sucrase is
|
153 | mostly beneficial in development, and in many cases, Babel or tsc will be more
|
154 | suitable for production builds.
|
155 |
|
156 | ## Motivation
|
157 |
|
158 | As JavaScript implementations mature, it becomes more and more reasonable to
|
159 | disable Babel transforms, especially in development when you know that you're
|
160 | targeting a modern runtime. You might hope that you could simplify and speed up
|
161 | the build step by eventually disabling Babel entirely, but this isn't possible
|
162 | if you're using a non-standard language extension like JSX, TypeScript, or Flow.
|
163 | Unfortunately, disabling most transforms in Babel doesn't speed it up as much as
|
164 | you might expect. To understand, let's take a look at how Babel works:
|
165 |
|
166 | 1. Tokenize the input source code into a token stream.
|
167 | 2. Parse the token stream into an AST.
|
168 | 3. Walk the AST to compute the scope information for each variable.
|
169 | 4. Apply all transform plugins in a single traversal, resulting in a new AST.
|
170 | 5. Print the resulting AST.
|
171 |
|
172 | Only step 4 gets faster when disabling plugins, so there's always a fixed cost
|
173 | to running Babel regardless of how many transforms are enabled.
|
174 |
|
175 | Sucrase bypasses most of these steps, and works like this:
|
176 | 1. Tokenize the input source code into a token stream using a trimmed-down fork
|
177 | of the Babel parser. This fork does not produce a full AST, but still
|
178 | produces meaningful token metadata specifically designed for the later
|
179 | transforms.
|
180 | 2. Scan through the tokens, computing preliminary information like all
|
181 | imported/exported names.
|
182 | 3. Run the transform by doing a pass through the tokens and performing a number
|
183 | of careful find-and-replace operations, like replacing `<Foo` with
|
184 | `React.createElement(Foo`.
|
185 |
|
186 | Because Sucrase works on a lower level and uses a custom parser for its use
|
187 | case, it is much faster than Babel.
|
188 |
|
189 | ## Performance
|
190 |
|
191 | Currently, Sucrase runs about 20x faster than Babel (even when Babel only runs
|
192 | the relevant transforms) and 8x faster than TypeScript. Here's the output of
|
193 | one run of `npm run benchmark`:
|
194 |
|
195 | ```
|
196 | Simulating transpilation of 100,000 lines of code:
|
197 | Sucrase: 469.672ms
|
198 | TypeScript: 3782.414ms
|
199 | Babel: 9591.515ms
|
200 | ```
|
201 |
|
202 | ## Project vision and future work
|
203 |
|
204 | ### Performance improvements
|
205 |
|
206 | * Rewrite the code to run in WebAssembly, either by changing it to be valid
|
207 | [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) or by
|
208 | rewriting it in Rust.
|
209 | * Explore the idea of a JIT to optimize the various token patterns that need to
|
210 | be matched as part of code transformation.
|
211 |
|
212 | ### New features
|
213 |
|
214 | * Implement more integrations, like a Browserify plugin.
|
215 | * Emit proper source maps. (The line numbers already match up, but this would
|
216 | help with debuggers and other tools.)
|
217 | * Rethink configuration and try to simplify it as much as possible, and allow
|
218 | loading Babel/TypeScript configurations.
|
219 | * Explore the idea of a tool that patches a Babel/TypeScript installation to
|
220 | use Sucrase instead, to make it even easier to try Sucrase on an existing
|
221 | codebase.
|
222 | * Explore the idea of extending this approach to other tools, e.g. module
|
223 | bundlers.
|
224 |
|
225 | ### Correctness and stability
|
226 |
|
227 | * Add more open source projects to the suite of projects that are tested
|
228 | automatically.
|
229 | * Set up a test suite that runs the compiled code and ensures that it is
|
230 | correct.
|
231 | * Add integrity checks to compare intermediate Sucrase results (like tokens and
|
232 | the role of each identifier and pair of curly braces) with the equivalent
|
233 | information from Babel.
|
234 | * Fix some known correctness loose ends, like import hoisting and fully
|
235 | replicating the small differences between Babel and the TypeScript compiler.
|
236 |
|
237 | ## License and attribution
|
238 |
|
239 | Sucrase is MIT-licensed. A large part of Sucrase is based on a fork of the
|
240 | [Babel parser](https://github.com/babel/babel/tree/master/packages/babel-parser),
|
241 | which is also MIT-licensed.
|
242 |
|
243 | ## Why the name?
|
244 |
|
245 | Sucrase is an enzyme that processes sugar. Get it?
|