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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better TypeScript support #1378

Open
mohsen1 opened this issue May 16, 2018 · 13 comments

Comments

@mohsen1
Copy link
Contributor

@mohsen1 mohsen1 commented May 16, 2018

馃挰 RFC Better TypeScript support

TypeScript is working out of the box for the most part but there are a few pain points:

Pain points

  • TypeScript module resolution algorithm is not implemented in Parcel. #202 This covers these configs:
    • baseUrl
    • paths
    • allowSyntheticDefaultImports
  • Compiler errors are not printed in the console #465
    • parcel-plugin-typescript adds it but console is not cleared after issue is resolved

Improvements

  • Automatically create and configure tsconfig
    • Once a ts or tsx file was imported but tsconfig is not present, create one
  • Automatically install @types packages #1161
  • Support for Custom Typescript transformers #699

馃敠 Context

TypeScript is pretty popular and having first class support for it in Parcel will attract a wider range of users.

馃捇 Examples

I tried cloning react-parcel-example and making repo states that demonstrate those pain points:

  1. JSX is not working in default mode (preserve):
  2. baseUrl config is not working
@fathyb

This comment has been minimized.

Copy link
Member

@fathyb fathyb commented May 16, 2018

Duplicates :

  • module resolution #202
  • type checking #465
  • auto install @types #1161

parcel-plugin-typescript implements the TypeScript module resolution (baseUrl, paths). allowSyntheticDefaultImports is not part of the module resolution algorithm, it's used for the module symbol resolution by the type-checker. If you are using TypeScript 2.8+ you should be able to import synthetic defaults.

The plugin is originally a spin-off of a PR implementing type-checking, but the feature wasn't well received by the community, so I guess it's better to leave the choice to the end user.

The TypeScript plugin will probably be integrated as a core plugin once we settle on a plugin RFC though (aka 2.0). The long term goal would be to integrate TypeScript just like we do with Babel, and let developers use a pure TypeScript toolchain with or without Babel.

@DeMoorJasper

This comment has been minimized.

Copy link
Member

@DeMoorJasper DeMoorJasper commented May 17, 2018

This will probably automatically happen once the new plugin system lands and we split up every plugin in a seperate package. Using parcel-plugin-ts as the default in that case. This will be part of the Parcel v2.0 update

@szagi3891

This comment has been minimized.

Copy link

@szagi3891 szagi3891 commented Jun 12, 2018

@DeMoorJasper - When could this happen?

@DeMoorJasper

This comment has been minimized.

Copy link
Member

@DeMoorJasper DeMoorJasper commented Jun 19, 2018

Please use the +1 button instead of adding comments saying +1

@parcel-bundler parcel-bundler deleted a comment from joseluisq Jun 19, 2018
@parcel-bundler parcel-bundler deleted a comment from uoziod Jun 19, 2018
@mihailik

This comment has been minimized.

Copy link

@mihailik mihailik commented Jun 27, 2018

1627 Support <script src="tsconfig.json"></script> as asset type might be a way to solve many of those issues.

Rather than stretch parcel's file-based current TS handling, allow a way to fall back into TS standard way, using tsconfig.json directly.

That way all the resolution, errors, special modes will reside in TS compiler, and act in familiar TS manner.

@QuantumInformation

This comment has been minimized.

Copy link

@QuantumInformation QuantumInformation commented Jan 24, 2019

This best loaders use native typescript as much as possible.

@devongovett devongovett referenced this issue Feb 17, 2019
0 of 3 tasks complete
SergeyZh pushed a commit to JetBrains/intellij-community that referenced this issue Feb 25, 2019
Remove compiled version of start-up-visualizer from source code in favour of externally hosted (for now - https://ij-perf.develar.org)
In general, nothing stops us to continue providing because still it is small text only js file, but not clear does it worth it or not.

Migrate from parcel to webpack because:

1. SRI support 鈥 https://github.com/waysact/webpack-subresource-integrity (parcel issue: parcel-bundler/parcel#2003)
2. Full typescript support (including type checking) 鈥 https://github.com/TypeStrong/ts-loader & https://github.com/Realytics/fork-ts-checker-webpack-plugin (parcel issue: parcel-bundler/parcel#1378)
3. Externals support 鈥 https://webpack.js.org/configuration/externals/ (parcel issue: parcel-bundler/parcel#144) There is workaround, but still because of lack type checking for typescript parcel is no-go.

So, parcel is good for very small projects during experimenting but not suitable for any production usage. Yeach, a lot of things in webpack can be simplified without sacrificing user-friendly (so funny bug that documented flag `optimize-minimize` doesn't work if `mode` also specified - and so on), but as no webpack alternatives at the moment, it is ok to write monstrous webpack.config.js
@inad9300

This comment has been minimized.

Copy link

@inad9300 inad9300 commented Jun 7, 2019

Wow, this seems to have been completely abandoned. Despite TypeScript's increase in popularity. Still no type checks.

@mischnic

This comment has been minimized.

Copy link
Member

@mischnic mischnic commented Jun 7, 2019

We are working on this for Parcel 2.

@tgroutars

This comment has been minimized.

Copy link

@tgroutars tgroutars commented Jun 7, 2019

@mischnic Awesome, is there an issue we can follow for updates on parcel 2?

@mihailik

This comment has been minimized.

Copy link

@mihailik mihailik commented Jun 8, 2019

@tgroutars comment above refers to Parcel 2/TypeScript transformer:

Screenshot from 2019-06-08 21-21-24

Mind you, that PR is old and not handling type checks (yet?)

@mischnic

This comment has been minimized.

Copy link
Member

@mischnic mischnic commented Jun 8, 2019

The current PR is #3083 (but doesn't have type checking either)

@DeMoorJasper

This comment has been minimized.

Copy link
Member

@DeMoorJasper DeMoorJasper commented Jun 9, 2019

Some initial work on typechecking: see #3142

@nexussays

This comment has been minimized.

Copy link

@nexussays nexussays commented Jul 18, 2019

I posted a workaround for type errors in the console in a comment in #465 that others might find useful: #465 (comment)

I'm cross-posting because there are several issues on this topic and I'm not actually sure where I arrived from google; so this will hopefully save everyone else some time going through GitHub issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can鈥檛 perform that action at this time.