feat(transformer): add transform-typescript boilerplate

[Boshen]

No description provided.

[Boshen]

• feat(transformer): add proposal-decorators #2868
• feat(transformer): add react plugins #2867
• feat(transformer): add transform-typescript boilerplate #2866 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on Graphite

[codspeed-hq]

CodSpeed Performance Report

Merging #2866 will not alter performance

_{Comparing 03-30-feat_transformer_add_transform-typescript_boilerplate (fb1f63b) with main (c1a2958)}

Summary

✅ 36 untouched benchmarks

[Boshen]

A plugin can be turned off, we haven't decided which one is better:

pub struct Transformer<'a> {
    typescript: Option<TypeScript>,
}

or

#[derive(Debug, Default, Clone)]
pub struct TransformOptions {
    pub typescript: Option<TypeScriptOptions>,
}

A None indicates the plugin is turned off, both methods have tradeoffs, we'll bike-shed this later.

[rzvxa]

A plugin can be turned off, we haven't decided which one is better:

pub struct Transformer<'a> {
    typescript: Option<TypeScript>,
}

or

#[derive(Debug, Default, Clone)]
pub struct TransformOptions {
    pub typescript: Option<TypeScriptOptions>,
}

A None indicates the plugin is turned off, both methods have tradeoffs, we'll bike-shed this later.

Aren't they both needed? A None option means the plugin is not turned on and would result in a None transformer.

[Boshen]

Aren't they both needed? A None option means the plugin is not turned on and would result in a None transformer.

True. I was thinking about eliminating if let Some(plugin) = &self.plugin and hide this check inside each individual plugin.

I'll do some follow up PRs.

[rzvxa]

Well, I guess we can have the plugin options set to default when it's disabled but It means that we need to have some other way to configure our list of plugins. What is your alternative for it? When fetching the options to initialize the transformer we need to return None anyway in order to notify the Transformer to not create this plugin.

[rzvxa]

True. I was thinking about eliminating if let Some(plugin) = &self.plugin and hide this check inside each individual plugin.

You mean when calling the transform methods inside our main Transformer?

[Boshen]

The previous version had something like this all over the place

  self.es2021_logical_assignment_operators.as_mut().map(|t| t.add_vars_to_statements(stmts));
  self.es2020_nullish_coalescing_operators.as_mut().map(|t| t.add_vars_to_statements(stmts));
  self.es2016_exponentiation_operator.as_mut().map(|t| t.add_vars_to_statements(stmts));
  self.es2015_arrow_functions.as_mut().map(|t| t.transform_statements(stmts));

I was thinking about changing it to

self.es2021_logical_assignment_operators.add_vars_to_statements(stmts);

And hide the Option check inside the add_vars_to_statements function.

This seems like a burden to plugin authors, not a really good idea.

I'll bike-shed this a bit later.

[rzvxa]

Yes, we have to wait to make the call on this one until the mutability is figured out, Since as we discussed in here we might need a macro for applying the transformation which can also be used to hide these checks.

[Boshen]

Merge activity

• Mar 30, 8:48 AM EDT: @Boshen merged this pull request with Graphite.