TypeScript is working out of the box for the most part but there are a few pain points:
### Pain points
baseUrl
paths
allowSyntheticDefaultImports
parcel-plugin-typescript
adds it but console is not cleared after issue is resolved tsconfig
ts
or tsx
file was imported but tsconfig
is not present, create one@types
packages #1161TypeScript is pretty popular and having first class support for it in Parcel will attract a wider range of users.
I tried cloning react-parcel-example and making repo states that demonstrate those pain points:
baseUrl
config is not workingDuplicates :
@types
#1161parcel-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.
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
@DeMoorJasper - When could this happen?
Please use the +1 button instead of adding comments saying +1
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.
This best loaders use native typescript as much as possible.
Wow, this seems to have been completely abandoned. Despite TypeScript's increase in popularity. Still no type checks.
We are working on this for Parcel 2.
@mischnic Awesome, is there an issue we can follow for updates on parcel 2?
@tgroutars comment above refers to Parcel 2/TypeScript transformer:
Mind you, that PR is old and not handling type checks (yet?)
The current PR is #3083 (but doesn't have type checking either)
Some initial work on typechecking: see https://github.com/parcel-bundler/parcel/pull/3142
I posted a workaround for type errors in the console in a comment in #465 that others might find useful: https://github.com/parcel-bundler/parcel/issues/465#issuecomment-512720643
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.
I created an issue for Parcel 2 about the incomplete TypeScript support, and the official response by @DeMoorJasper is that Parcel 2 will effectively behave the same as Parcel 1 by stripping out TypeScript and treating it as JavaScript with babel. TypeScript code will not be compiled, so there will be no type checking or compiler errors. If you have a desire for real TypeScript support in Parcel 2, please comment in the new RFC: https://github.com/parcel-bundler/parcel/issues/4022
Most helpful comment
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