Add '.ts' and '.tsx' to default extensions #6027

ghost · 2017-07-28T22:39:15Z

Q	A
Patch: Bug Fix?	No
Major: Breaking Change?	Technically, if people had '.js' and '.ts' files together and depended on babel to pick up only the '.js' files.
Minor: New Feature?	Yes
Deprecations?	No
Spec Compliancy?	No
Tests Added/Pass?	Tests pass
Fixed Tickets
License	MIT
Doc PR
Dependency Changes	No

Adds .ts and .tsx to the default list of extensions. Also avoids compiling .d.ts files, which are just declarations and should not transpile to anything.

mention-bot · 2017-07-28T22:39:17Z

@Andy-MS, thanks for your PR! By analyzing the history of the files in this pull request, we identified @loganfsmyth, @existentialism and @hzoo to be potential reviewers.

loganfsmyth · 2017-07-29T00:10:14Z

Is there existing tooling for TS as a Node require hook? Curious if we have to worry about conflicts for this.

ghost · 2017-07-29T00:27:46Z

I think ts-node does that.

hzoo · 2017-07-29T00:51:10Z

We have some existing issues in this repo about it I think

TheLarkInn · 2017-08-16T16:34:35Z

Can presets/plugins modify the default extension set? Could this be added into a preset capability instead?

I'm not sure how I feel about TS being pulled in by default any time babel is used (if I'm reading the PR correctly).

jridgewell · 2017-08-24T00:18:58Z

TS won't be pulled in, it only tells babel to consider .ts extensions as JS.

loganfsmyth · 2017-08-24T00:22:35Z

I'm definitely concerned with enabling these automatically for all usecases. I think for babel-cli it's reasonable, but I definitely worry that enabling it automatically for babel-register will make it conflict with cases where people want to use both ts-node and babel-register.

hzoo · 2017-08-28T19:26:34Z

Ok then we just need to document what users need to do

alloy · 2017-10-02T20:37:01Z

As mentioned in #6353 I ran into the situation where I expected that babel-register would automatically load TS files. However, in my case I explicitly enable typescript support in my .babelrc with { "presets": ["es2015", "typescript"] }, in which case I think it would be reasonable to assume that I want babel-register to load TS files.

hzoo · 2017-10-02T20:37:26Z

I think for babel-cli it's reasonable

Can we modify the PR to just do this then? I don't know how we are differentiating that atm though, unless it is just not changing babel-cli/src/_babel-node.js

hzoo · 2017-10-02T20:39:13Z

@loganfsmyth is the issue is what happens if someone happens to use both ts-node and babel-node, dono if we should handle that correctly or just error in some way?

hzoo · 2017-10-19T19:52:31Z

I'm good with at least letting babel-cli handle .ts automatically for now

lostpebble · 2017-11-02T14:56:39Z

Currently I'm finding it impossible to use Typescript with babel directly - the only way is through webpack, but I'd preferably like to just use babel-register for easier development configuration.

I'm busy with Node.js server code, so webpack is a bit of a round trip.

Would love to see this pushed through as soon as possible. In the same boat as @alloy

loganfsmyth · 2017-11-02T17:19:43Z

@lostpebble For now you need to tell babel-register to handle .ts files, e.g.

require("babel-register")({
    extensions: ['.js', '.jsx', '.ts', '.tsx'],
});

lostpebble · 2017-11-03T08:00:02Z

Thanks @loganfsmyth ! Couldn't find anything on the babel site and tried using babel-node with the command line option --extensions but for some reason that was causing issues with my code (seems like it wasn't reading .babelrc correctly and struggled with es6 imports) - I figured it was just using babel-register behind the scenes so it was quite confusing that it suddenly couldn't transform my code now.

Would be great if we could also set this in the babelrc configuration file (surely anything that could be set in the options {} object or command line options should be configurable there as well) to keep things nice and centralised.

loganfsmyth · 2017-11-03T17:02:09Z

Would be great if we could also set this in the babelrc configuration file (surely anything that could be set in the options {} object or command line options should be configurable there as well) to keep things nice and centralized.

I agree with you, but unfortunately we're not at a point where it is feasible without other bigger changes to how Babel approaches compilation.

loganfsmyth · 2018-03-11T02:39:34Z

I've been exploring this a bit today to see what seems workable. I think we're getting to a place where we can to have babel/core have a set of extensions that it handles, like ignore. I've got a bit of a prototype so far that seems to work.

The main place where I'd expect complaints if we did only that is babel-register (and thus babel-node), because it relies on Node's require hooks and that needs to know the extensions up front. Once #7358 lands though, I'm thinking we could make it so that if the Typescript preset is mentioned in babel.config.js (but not .babelrc), babel-register could automatically pick it up and take over the ".ts" and ".tsx" extensions too.

xtuc

I'm 👍 with the idea

xtuc · 2018-03-14T13:10:10Z

packages/babel-register/README.md


 All subsequent files required by node with the extensions `.es6`, `.es`, `.jsx`,
-`.mjs`, and `.js` will be transformed by Babel.
+`.mjs`, `.ts`, `.tsx`, and `.js` will be transformed by Babel.


To clarify could we add that it also includes .d.ts?

Need to be careful with that; .d.ts files are metadata only; they're not code and cannot become code. Having code in them is a syntax error.

Even if there was some syntax you wanted to transform, having to transform it makes the .d.ts useless as that means TypeScript can't use its metadata as-is.

The PR explicitly ignore them, and I just wanted to make it clear. While it doesn't really affect the user, it's a big implementation detail on our side.

@loganfsmyth just made a suggestion in slack, maybe could make a new issue for it.

Logan Smyth [8:22 PM]
I've been thinking about #6027 and #3741 more generally. It seems like it'd be pretty easy to have babel-core include an extensions object in its options, so for example the typescript preset could just say:

extensions: { ".ts": true, ".tsx": true, ".d.ts": false, },

in its body to tell Babel to start processing .ts files.

We could for instance make @babel/core essentially ignore a file if its extension isn't given in the config or Babel's default extension list.

My main question at that stage is, does it make sense to keep these as booleans, or to just go all the way and make the extensions be string | null with the string value being a sourceType? Then we could easily give .ts files a sourceType of its own sourceType which I've mentioned before as potentially being nice anyway, since we'll probably want that so that the CLI for instance could properly output files with .ts extensions if the user enabled the typescript syntax plugin but not the transform.

I know Webpack has more complex logic around file types, so maybe we could consider an approach that that over simple sourceTypes too, hard to say.

Yeah, I remember about that. Just an idea @loganfsmyth, what if we stored this configuration in the presets, like the React preset would enable the JSX syntax or TS the TS syntax.

chrisgervang · 2018-04-16T05:23:32Z

Any updates on this? Would love to see this merged. At the moment, every downstream build tool (babelify, gulp-babel, babel-cli, babel-node, etc) has to be configured to look for these file extensions when using the typescript preset. Would be fantastic to have zero-config support for .ts and .tsx since there is a preset now.

brainkim · 2018-06-14T06:48:04Z

Just a small update. I have a project which I’ve upgraded to typescript and the test command was:

$ mocha --require @babel/polyfill --require @babel/register

Would be nice if I could use this same command with TypeScript.
Alternatively, why can’t I define the extensions I want in my .babelrc and have @babel/register read it from there?

LinusU · 2018-08-01T09:46:33Z

Any updates on this? I would love to see it merged.

If there is anything that needs to be done, I would be happy to help out!

loganfsmyth · 2018-08-01T17:23:09Z

I think where we've settled on this, for Babel 7.x anyway, is that this may need to remain opt-in, unfortunately. This PR as-is seems like it would have unwanted side-effects because if .ts is processed by default, it would break users trying to use @babel/register alongside ts-node, even when preset-typescript isn't actually enabled in the user's own Babel configuration. That would mean we'd actually need additional logic to then opt out of .ts files being parsed by default, or else risk throwing errors.

I have a sense of what I think Babel should consider for this issue, but it's likely something at this point that would land as an opt-in feature in Babel 7.x, and then we could explore enabling it by default in 8.x. This would involve making extensions part of user configuration and tied into the ignore system that Babel has, rather than having them be one-off configuration for each separate Babel-related wrapper utility (like /register and /cli).

kohlmannj · 2018-08-02T00:58:37Z

@loganfsmyth Those are good reasons; thanks for explaining in detail.

I realize you noted issues with #3741 as well, but given where this discussion seems to be headed, I would appreciate fresh consideration of an extensions config property in .babelrc / babel.config.js. Thanks!

loganfsmyth · 2018-08-02T16:38:53Z

Yeah, I think extensions is likely the way to go if we can get it worked out, there's just a lot of little issues to figure out around how it works, and we're doing out best not to block 7.x with new features at this point.

deepsweet · 2018-08-11T20:42:05Z

Meanwhile I've published a temporary @babel/register wrapper for my own needs, maybe someone else will find it useful as well.

loganfsmyth · 2018-09-08T00:29:49Z

Since this would be a breaking change to land in 7.x, I'm going to close it. I've filed #8652 with a link here as a place to continue this general discussion though.

Add '.ts' and '.tsx' to default extensions

84d11f5

xtuc added the area: typescript label Aug 11, 2017

danez closed this Aug 31, 2017

danez reopened this Aug 31, 2017

danez changed the base branch from 7.0 to master August 31, 2017 17:01

ghost mentioned this pull request Oct 2, 2017

[BUG] babel-node does not transform TypeScript source. #6353

Closed

hzoo added the Priority: High label Oct 27, 2017

hzoo mentioned this pull request Jan 19, 2018

@babel/cli: default the src/out directory #7237

Open

xtuc approved these changes Mar 14, 2018

View reviewed changes

loganfsmyth mentioned this pull request Mar 25, 2018

added typescript extensions for the DEFAULT_EXTENSIONS const (#7620) #7626

Closed

chrisgervang mentioned this pull request Apr 16, 2018

Using @babel/preset-typescript, unsure how to include .ts and .tsx file extensions with gulp-babel babel/gulp-babel#153

Closed

loganfsmyth mentioned this pull request Sep 8, 2018

[feature request] Better handling of file extensions #8652

Open

loganfsmyth closed this Sep 8, 2018

ghost deleted the ts-tsx branch November 7, 2018 18:32

lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 4, 2019

lock bot locked as resolved and limited conversation to collaborators Oct 4, 2019

Uh oh!

Add '.ts' and '.tsx' to default extensions #6027

Add '.ts' and '.tsx' to default extensions #6027

Uh oh!

Conversation

ghost commented Jul 28, 2017

Uh oh!

mention-bot commented Jul 28, 2017

Uh oh!

loganfsmyth commented Jul 29, 2017

Uh oh!

ghost commented Jul 29, 2017

Uh oh!

hzoo commented Jul 29, 2017

Uh oh!

TheLarkInn commented Aug 16, 2017

Uh oh!

jridgewell commented Aug 24, 2017

Uh oh!

loganfsmyth commented Aug 24, 2017

Uh oh!

hzoo commented Aug 28, 2017

Uh oh!

alloy commented Oct 2, 2017

Uh oh!

hzoo commented Oct 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hzoo commented Oct 2, 2017

Uh oh!

hzoo commented Oct 19, 2017

Uh oh!

lostpebble commented Nov 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loganfsmyth commented Nov 2, 2017

Uh oh!

lostpebble commented Nov 3, 2017

Uh oh!

loganfsmyth commented Nov 3, 2017

Uh oh!

loganfsmyth commented Mar 11, 2018

Uh oh!

xtuc left a comment

Choose a reason for hiding this comment

Uh oh!

xtuc Mar 14, 2018

Choose a reason for hiding this comment

Uh oh!

Jessidhia Mar 14, 2018

Choose a reason for hiding this comment

Uh oh!

xtuc Mar 21, 2018

Choose a reason for hiding this comment

Uh oh!

hzoo Mar 21, 2018

Choose a reason for hiding this comment

Uh oh!

xtuc Mar 21, 2018

Choose a reason for hiding this comment

Uh oh!

chrisgervang commented Apr 16, 2018

Uh oh!

brainkim commented Jun 14, 2018

Uh oh!

LinusU commented Aug 1, 2018

Uh oh!

loganfsmyth commented Aug 1, 2018

Uh oh!

kohlmannj commented Aug 2, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loganfsmyth commented Aug 2, 2018

Uh oh!

deepsweet commented Aug 11, 2018

Uh oh!

loganfsmyth commented Sep 8, 2018

Uh oh!

Reviewers

Assignees

hzoo commented Oct 2, 2017 •

edited

Loading

lostpebble commented Nov 2, 2017 •

edited

Loading

kohlmannj commented Aug 2, 2018 •

edited

Loading