Skip to content

Instantly share code, notes, and snippets.

@fabiosantoscode
Created April 23, 2020 16:55
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save fabiosantoscode/94c3585db3c48cda77a822edf8471716 to your computer and use it in GitHub Desktop.
Save fabiosantoscode/94c3585db3c48cda77a822edf8471716 to your computer and use it in GitHub Desktop.

Problem statement

TL;DR: Tools which transpile code should focus on compiling code and not adapting to every bundler, and tools (like bundlers) which need to get that code transpiled shouldn't have to write adapters for every tool which exists. This wastes the community's time and ultimately hinders novel projects.

Developer's perspective

Case 1: A developer wants to use something new which employs custom syntax, but they're using React Native, or a bundler which is not popular enough to get a custom made plugin for it. They would have to manage another compilation pass and give up on the ordeal.

Case 2: A user already has a bundler set up for their project using custom syntax, but they want to:

  • Add a testing framework
  • Generate documentation from comments
  • Generate code from decorators at compile time
  • Use macros, transparent or not, at compile time

Transpiler author's perspective

A language extension, macro or optimization author needs to create a lot of plugins, one for every popular bundler or compiler.

After all this work, they leave out users of more fringe bundlers and other tools.

Examples of tools which have this issue:

  • A minifier
  • An optimisation pass
  • A tool which infers types and adds jsdoc comments to your code.
  • A tool which extracts your css-in-js into automatically generated CSS

If a tool replaces non-standard syntax or changes how standard syntax works it also has to be made to work for every test runner, linter, development server, etc.

Examples:

  • A syntax which embeds or is embedded in EcmaScript (like, JSX, Svelte templates, or MDX)
  • New syntax from future ES features such as decorators
  • A tool which enables resolving ES modules from custom locations
  • A tool which enables resolving non-ES modules with new file types (such as CSS, images or Rust)

Bundler author's perspective

Bundlers usually have to create a lot of plugins for themselves, just to support the baseline of third party tools that people use.

They should be able to make use of tools which weren't specifically made for them.

@fabiosantoscode
Copy link
Author

fabiosantoscode commented Apr 28, 2020

Prior art on this is Rome. It's a valid solution to the issue, but there are several problems with doing everything in one tool (or an entity providing multiple tools made to work together).

@fabiosantoscode
Copy link
Author

I wrote a very tough draft of what I think could solve parts of the problem. It includes AST style negotiation in the vein of what we have in HTTP with the accept header. This way as long as the bundler can convert espree into estree, a tool outputting espree can work with a tool getting estree as input.

Also, if the tool can output more than one thing, it can be specified. For example Terser can output a string as well as a tree. It's convenient to emit a string at the end of the chain, and a tree in the middle.

https://gist.github.com/fabiosantoscode/ce18472f917486b32b8bddb843284369

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment