Skip to content

Tags: hneiva/decaffeinate

Tags

v3.1.1

Toggle v3.1.1's commit message
fix: don't generate useless `map` calls for array comprehensions (dec…

…affeinate#1125)

Fixes decaffeinate#749

v3.1.0

Toggle v3.1.0's commit message
feat: add an option to avoid using Array.prototype.includes (decaffei…

…nate#1124)

Fixes decaffeinate#1102

This just adds back the old `__in__` implementation.

v3.0.0

Toggle v3.0.0's commit message
feat: enable suggestions system, update default options (decaffeinate…

…#1121)

Fixes decaffeinate#1107

Implement several defaults changes as described in decaffeinate#1107. This involved updating
the options structure, the CLI code, the docs, and the tests. This also includes
various other little cleanups to the docs and generated code to better match the
new system.

Also rename `disableSuggestions` to `disableSuggestionComment`, since maybe in
the future there will be a different way of displaying suggestions.

BREAKING CHANGE:

JavaScript files produced by decaffeinate now have a comment at the top of the
file with suggestions on cleanup steps. The new `--disable-suggestion-comment`
flag disables this behavior.

decaffeinate now prefers `const` for variables when possible. The
`--prefer-const` option is now a no-op, and a new `--prefer-let` option opts
into the old behavior.

decaffeinate no longer tries to convert code to JS modules by default. There are
three configurations to choose from:
* To keep code as CommonJS (or whatever the original code was using), specify no
  options. Previously, this was the `--keep-commonjs` option.
* To convert code to JS modules in a way that always generates a default export
  for correctness reasons, specify `--use-js-modules`. Previously, this was the
  `--force-default-export` option.
* To convert code to JS modules and use named exports on a best-effort basis,
  specify `--use-js-modules --loose-js-modules`. Previously, this was the
  default option.

decaffeinate now automatically inserts a code snippet at the top of constructors
using `this` before `super`, which allows them to behave as expected, but only
when using Babel or TypeScript under certain configurations. There are three
configurations to choose from:
* To insert the Babel/TypeScript workaround code snippet when necessary, specify
  no options. Previously, this was the `--enable-babel-constructor-workaround`
  option.
* To produce code that uses `this` before `super` (which is well-formed but
  crashes at runtime), specify `--disable-babel-constructor-workaround`.
  Previously, this was the `--allow-invalid-constructors` option.
* To make decaffeinate give an error when code would use `this` before `super`,
  specify `--disallow-invalid-constructors`. Previously, this was the default
  behavior.

v2.58.0

Toggle v2.58.0's commit message
feat: insert suggestion comments in generated code (decaffeinate#1120)

Progress toward decaffeinate#1107

Rather than printing suggestions out to the console, I think it actually makes
more sense to include them in the code. This should make them really hard to
miss and be especially useful for the use case of doing a large conversion and
then going through each file as a follow-up task. I added a `disableSuggestions`
flag to disable this behavior if people want.

For now, the `disableSuggestions` is always set to true from the CLI, meaning
the feature can't be accessed normally now; it's just exposed to tests. I'll
change it to false by default soon along with all of the other breaking changes.

v2.57.0

Toggle v2.57.0's commit message
feat: add a --loose option that enables all loose options (decaffeina…

…te#1118)

Progress toward decaffeinate#1107

v2.56.34

Toggle v2.56.34's commit message
fix: automatically detect all suggestions (decaffeinate#1116)

Progress toward decaffeinate#1107

The suggestions system doesn't do anything yet, but decaffeinate can not detect
all suggestions to use for a given CoffeeScript file.

Also fix some mistakes in suggestion numbering.

Also fix some bugs discovered while working through the details:
* `try` expressions weren't acting as a proper implicit return parent, so a try
  expression within a loop expression was appending to the array rather than
  returning within the IIFE.
* Classes in CoffeeScript have their own scope, and the scope logic wasn't doing
  that. This meant that static methods were seen as top-level `this` usages, and
  possibly other subtle bugs.

v2.56.33

Toggle v2.56.33's commit message
fix: don't crash when using a binary operator with range or extends (d…

…ecaffeinate#1114)

Fixes decaffeinate#1113

Most binary operations have a plain operator token in them or already handled a
custom token type as a special case, but these two cases weren't handled.

v2.56.32

Toggle v2.56.32's commit message
fix: remove semicolons when turning blocks into expressions (decaffei…

…nate#1109)

Fixes decaffeinate#1108

Now that all lone semicolons are treated in the AST as empty blocks, they turn
into `undefined` as expected when treated as an expression, but the semicolon is
still there. To fix this, we can just detect if the block ends in a semicolon
(even for non-empty blocks) and remove it.

v2.56.31

Toggle v2.56.31's commit message
fix: force `throw` targets to be expressions (decaffeinate#1097)

Fixes decaffeinate#1096

v2.56.30

Toggle v2.56.30's commit message
fix: properly add variable declarations for IIFE loop assignees (deca…

…ffeinate#1094)

Fixes decaffeinate#750

The solution here is similar in spirit to decaffeinate#639, but has some differences.
Rather than allowing the loop to become an IIFE and letting
add-variable-declarations put in the declaration for us, we now explicitly add
declarations for any index/value bindings that we know will be in IIFEs, as long
as there is at least one usage of the variable outside of the loop. This
required a lot of coordination between BlockPatcher and all of its descendant
ForPatchers during initialize so that patching can be done in the proper order.