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

auto-strip typescript #269

Open
stefanpenner opened this issue Feb 21, 2019 · 8 comments
Open

auto-strip typescript #269

stefanpenner opened this issue Feb 21, 2019 · 8 comments

Comments

@stefanpenner
Copy link
Member

stefanpenner commented Feb 21, 2019

Should we simply auto-strip typescript by default? This would mitigate the need for typescript'd code to be prebuilt built.

cc @rwjblue / @chriskrycho

@chriskrycho
Copy link
Contributor

chriskrycho commented Feb 21, 2019

Huh, interesting thought. So then the work of ember-cli-typescript and similar would just be providing the build/publish hooks to let people generate their type definitions (as desired) and injecting build failures if they so desired. 🤔 cc. @dfreeman @dwickern @mike-north

@rwjblue
Copy link
Member

rwjblue commented Feb 21, 2019

What do you mean RE: auto-stripping? Remove from the build without compiling from .ts -> .js? How would that actually work?

@chriskrycho
Copy link
Contributor

No, just doing the "compile" step for TS as Babel understands it – just stripping the types.

@stefanpenner
Copy link
Member Author

@rwjblue Babel/swc support a non/type checking ts -> JavaScript transform, this transform being enabled is what I meant by auto-stripping

@dfreeman
Copy link
Contributor

This is effectively what ember-cli-typescript@2 is already doing today (though granted you have to opt into it by adding e-c-ts as a dependency).

The prepublish build step we have there is for generating declaration files in a location discoverable by tsc, since the actual sources in addon/**/*.ts won't have the addon/ segment in their ultimate import path.

@stefanpenner
Copy link
Member Author

stefanpenner commented Feb 22, 2019

@dfreeman ya, I wonder though if we should consider pushing it down the stack to reduce maintenance/keep stuff in sync, enable this by default. That may allow e-c-ts to focus on the typechecking side of things

@dfreeman
Copy link
Contributor

dfreeman commented Feb 22, 2019

It's an interesting idea. Today adding the plugin is pretty trivial for us to do, but in the future (e.g. if we start getting things like swc in the mix) I can definitely see the appeal of not having to manage the transpilation setup ourselves in ember-cli-typescript.

On the other hand, there's a maintenance/sync problem on the TypeScript language side as well. @babel/plugin-transform-typescript isn't the only thing you necessarily need to include to get full TypeScript support. Today you also have to add the class properties plugin (and potentially decorators), but the set of needed plugins for full coverage will be a moving target if TS adopts proposals before they hit stage 4 and get handled automatically by present-env. Is that something we'd want to take on handling here?

@rwjblue
Copy link
Member

rwjblue commented May 29, 2020

FWIW, we have made a bit of progress here. Currently, ember-cli-babel will detect if ember-cli-typescript is present (and at the right minimum version) and add the babel plugins itself.

That was added in #314.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants