kensho-technologies / babel-preset Goto Github PK

This would be a convenience, forwarded as pragma to the React preset and jsxPragma to the Typescript preset, if either are enabled.

Not sure if it's justifiable as a top-level option.

The runtime transform has an option to use ESM versions of its helpers. We could enable this when {modules: false}.

See the docs. This is required for Babel to support polyfills present in newer versions.

Maybe we can use the same version loading strategy as for @babel/runtime:

Follow-up to #106.

We could use an override to be a bit stricter here, to account for third-party code using a wider range of language features than we do internally. (This will become more common over time as libraries transpile themselves less aggressively.)

We could potentially special case @kensho packages to use the regular assumptions there.

We currently hardcode a target version of Node for library builds:

We're adding engines field to all of our projects. This corresponds to the consuming environment so the lowest satisfying version is exactly the one that we'd want as the default Node target when transpiling libraries.

We could try to detect this automatically:

1. Starting from the file path being transpiled, traverse upwards to find a package.json.
2. If one exists, check if it has an engines.node field.
3. If it does, parse it and use the lowest satisfying version as the default target.
4. Otherwise, fall back to the current explicit value as a default? Or throw, but provide an option to pass an explicit value if the auto-detection doesn't fit the use case?

The current snapshot-based is getting unwieldy:

• Some of the fixtures are quite large and it's increasingly hard to understand what each test is verifying and what to expect from the output.
• It runs every test through every env, even though some of the tests' output is only useful to compare across a subset of the envs.
• Including the input code as one of the snapshots was well-intentioned, but, in practice, it's hard to parse the snapshot file well enough to directly compare input/output.
• GitHub's diff rendering of the snapshot file often fails to correspond snapshots based on their title, so the output is a mess.

I think we should try out inline snapshots with a new test suite that is more locally-scoped. We can include a few kitchen sink tests to get the high-level integration coverage that our current suite covers as well.

The forced plugin inclusion list is getting pretty long:

Most of it is only necessary for projects using webpack 4. #91 removes it entirely, but we'll likely be split between 4 and 5 for awhile.

We could add something like a webpack option to the preset to specify the version used by the consuming app. It would only affect development and production envs, modifying the forced inclusion list as needed. A simple implementation would take either 4 or 5. A more advanced implementation would take the full version, since some newer syntax is only supported in more recent versions of 5 (e.g., see the note here).

I also wonder if Babel has considered having babel-loader do this automatically. NTS to look into that.

See https://babeljs.io/docs/en/assumptions.

We generally don't want to transpile stable features there.

Before the next major release. We no longer use it anywhere.

See the docs and the announcement.

Going forward, this will be the preferred way to override the browserslist env, since it integrates with plugins/presets beyond @babel/preset-env such as the new polyfill transforms.

Unfortunately, it's not a straightforward migration because the top-level option can't be specified in presets. I opened babel/babel#13317 to see whether this might change. If not, we'll need to add at least some config to each app.

{emotion: true, react: {runtime: 'classic'}} in 'development' environment causes Babel to crash:

SyntaxError: /index.js: pragma and pragmaFrag cannot be set when runtime is automatic.
> 1 | import * as React from "react";
    | ^
  2 | 
  3 | export default function MyComponent() {
  4 |   return <div />;
    at File.buildCodeFrameError (/node_modules/@babel/core/lib/transformation/file/file.js:250:12)
    at NodePath.buildCodeFrameError (/node_modules/@babel/traverse/lib/path/index.js:144:21)
    at PluginPass.enter (/node_modules/@babel/helper-builder-react-jsx-experimental/lib/index.js:167:26)
    at newFn (/node_modules/@babel/traverse/lib/visitors.js:175:21)
    at NodePath._call (/node_modules/@babel/traverse/lib/path/context.js:55:20)
    at NodePath.call (/node_modules/@babel/traverse/lib/path/context.js:42:17)
    at NodePath.visit (/node_modules/@babel/traverse/lib/path/context.js:92:31)
    at TraversalContext.visitQueue (/node_modules/@babel/traverse/lib/context.js:112:16)
    at TraversalContext.visitSingle (/node_modules/@babel/traverse/lib/context.js:84:19)
    at TraversalContext.visit (/node_modules/@babel/traverse/lib/context.js:140:19) {
  code: 'BABEL_TRANSFORM_ERROR'
}

It's caused by a quirk in the way that the Emotion preset supports both runtimes simultaneously: emotion-js/emotion#2082. Not sure if the Emotion behavior will change but it can be fixed here by only setting the development option of the Emotion preset in the automatic runtime.