Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[planned] don't include fallback js transpilers #2076

Open
3 tasks done
kellymears opened this issue Feb 1, 2023 · 1 comment
Open
3 tasks done

[planned] don't include fallback js transpilers #2076

kellymears opened this issue Feb 1, 2023 · 1 comment
Assignees
Labels
in-progress Active work
Milestone

Comments

@kellymears
Copy link
Member

Agreement

The feature

It seemed like a good idea to include a fallback transpiler but it complicates things a lot more than anticipated. If you aren't using babel then it's also pretty substantial baggage.

In [email protected] I would like to require projects specify the transpiler of their choice as a dependency.

Use case

For example, in a React project using [email protected] you could install:

  • @roots/bud
  • @roots/bud-react

This implicitly includes @roots/bud-babel. If you install another transpiler it takes precedence over the babel default. So, this set of dependencies will end up using swc instead of babel:

  • @roots/bud
  • @roots/bud-react
  • @roots/bud-swc

This seems cool but it means a fair bit of extra code, mostly conditional statements related to inferring which transpiler is installed. It's not really costly computation but it is messy and when we get it wrong it can be frustrating.

If you're using some other transpiler you still wind up with babel installed, which is wasteful.

In the case of @roots/bud-typescript the user may very well want to use both @roots/bud-babel along with @roots/bud-typescript. How do we know if they intended to? Right now users can be explicit by calling bud.typescript.useBabel() but this seems like it's having the opposite of the intended effect: it's complicating things instead of simplifying them.

In [email protected] I'd like to just have the user simply pick for their project upfront.

For swc:

  • @roots/bud
  • @roots/bud-react
  • @roots/bud-swc

For tsc:

  • @roots/bud
  • @roots/bud-react
  • @roots/bud-typescript

For tsc and babel:

  • @roots/bud
  • @roots/bud-react
  • @roots/bud-typescript
  • @roots/bud-babel

For esbuild:

  • @roots/bud
  • @roots/bud-react
  • @roots/bud-esbuild

For babel:

  • @roots/bud
  • @roots/bud-react
  • @roots/bud-babel

This is a breaking change as the choice will be required.

Notes

Affected extensions:

  • @roots/bud-react includes @roots/bud-babel as a fallback
  • @roots/bud-preset-recommend includes @roots/bud-babel as a fallback
@kellymears kellymears added this to the 7.0.0 milestone Feb 1, 2023
@kellymears kellymears pinned this issue Feb 6, 2023
@github-actions
Copy link

github-actions bot commented Apr 3, 2023

Message to comment on stale issues. If none provided, will not mark issues stale

@github-actions github-actions bot added the stale label Apr 3, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 11, 2023
@kellymears kellymears self-assigned this May 11, 2023
@kellymears kellymears reopened this May 11, 2023
@kellymears kellymears added in-progress Active work and removed stale labels May 12, 2023
kodiakhq bot pushed a commit that referenced this issue May 14, 2023
…2253)

Warn about missing compilers in `@roots/bud-preset-recommend` `register` callback.

See:
- #2076

## Type of change

**PATCH: backwards compatible change**
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in-progress Active work
Projects
None yet
Development

No branches or pull requests

1 participant