Project roadmap and ways others can contribute about sucrase HOT 9 OPEN

• d.ts and flow declarations generation
• resolve import aliases. ts: baseUrl, paths from tsconfig.json support, flow: module.name_mapper from .flowconfig

from sucrase.

@zerkalica

d.ts and flow declarations generation

Unfortunately I think this is too hard for Sucrase to do. I'm not 100% sure about flow declarations, but .d.ts generation is definitely out of scope.

As one example, d.ts generation relies on TypeScript's type inference algorithm, so this code:

export function foo() {
  return 3;
}

gets this type definition:

export declare function foo(): number;

Determining that 3 has type number maybe isn't conceptually so bad, but there are much more complicated cases (e.g. a variable that has a refined type due to previous control flow operations), and doing this right means that Sucrase would need to reimplement the whole TypeScript type system. TypeScript also infers types across files, and one design goal of Sucrase is that it can compile each file individually.

Sucrase is simple and fast because it just removes types and doesn't need to know the whole type system, so any features requiring type system knowledge or cross-file resolution are out of scope. The TypeScript support in Babel has the same limitations. Also, the main intended use case for Sucrase is development builds where iteration speed is important, and my understanding is the main use case for .d.ts files is production builds when shipping a library.

TypeScript recently added a new --emitDeclarationsOnly flag if you want to have Sucrase compile the JS and TypeScript compile the .d.ts files, so that's one way to get the build to work:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#new---emitdeclarationsonly

resolve import aliases. ts: baseUrl, paths from tsconfig.json support, flow: module.name_mapper from .flowconfig

What's the use case for path resolution? Sucrase just takes import statements in and produces either the same import or an equivalent require. All path resolution should happen later, when running the code emitted by Sucrase. Again, it's just like Babel in that sense. To be clear, Sucrase just transforms code and doesn't do any typechecking; you need to run typechecking separately.

from sucrase.

Path aliasing needed to avoid relative paths ../../ hell in libraries and applications above 1K SLOC.
Relative path is a big problem in js imports. There are many workarounds to fix it: tspath, path transform in awesome-typescript-loader, path transform in parcel-plugin-typescript. In babel environment people use babel-plugin-module-resolver.

from sucrase.

@zerkalica I see, thanks for explaining. At my work, we have webpack and node set up to accept absolute paths, so it's not needed at transpile time. In webpack, it's the resolve.modules setting, and in node, it's NODE_PATH. But I guess NODE_PATH won't be supported in ES modules (still experimental in node 10, but maybe node 12 will have them), as I understand things, so I can see why you might prefer to resolve paths at transpile time.

I want to keep the project focused and avoid feature creep, so I'd rather hold off on the feature for now, but if there's more demand for it, I could see it being added in the future. Some more thoughts/concerns:

• The feature would add a dependency on the filesystem. Currently Sucrase is just a string to string transform, which means it naturally runs in the browser and at least theoretically can run in WebAssembly. Adding synchronous file I/O for import resolution would add complexity and possibly hurt performance.
• There's already code dealing with imports, so this feature would need to safely interact with it in all configurations. It wouldn't really be an isolated plugin, so it would add complexity to the project as a whole. Part of the reason Sucrase is possible is that it's tackling a relatively small problem (removing types, transforming JSX), so the complexity is manageable.
• I could see a feature like this leading to a million configuration options, and I'd rather keep the project as low-configuration as possible.
• It arguably goes against the project vision of handling common language extensions and letting them run in node or the browser. Unlike Babel, Sucrase isn't really meant to be a platform for doing arbitrary code transformations.

Possibly a way to get this working at transpile time would be a two-phase step where you run Sucrase and then a separate import-rewriting step. I've thought about pulling the Sucrase parser into its own package so that anyone could make a separate transform with a fast parser. It would be a little less efficient than ideal, though, since you'd need to re-parse after the first transform is done. In this case, though, I bet you could get away with more superficial parsing than Sucrase needs, like just using regexes or something.

from sucrase.

Yes, @alangpierce , these are the features I consider important for TypeScrip support.

I do not yet know if this is possible with sucrase.
But I will watch the topics in anticipation of examples of solving the problem.

from sucrase.

Also you should try prepack #269

from sucrase.

I'll try to implement stuff around reports

from sucrase.

Mobile support: #451

from sucrase.

Allow Sucrase to read a tsconfig.json for its config (including which directories to compile and which to exclude, etc).

Implemented in #509

from sucrase.