Parcel 2: TypeScript automatic zero configuration not type checking or reading tsconfig.json #4022
Comments
|
You have to use a parcelrc file with the transformer-tsc for tsconfig to do anything and for typechecking you need to add the ts validator to the config. The zero config default we took is just running babel we might however want to detect typescript in the babel transformer so it’s truly zero config Sent with GitHawk |
|
Thank you for the reply. I agree with what you said and understand the current configuration requirements. To clarify, I'm not confused about how it works in Parcel 2, I'm suggesting that current Parcel 2 behavior is incorrect. The main value proposition of TypeScript is compile-time typing and checking. Parcel 2 currently ignores all type checking by default. This was a problem with Parcel 1 that you had previously suggested would be fixed in Parcel 2. I am excited to test Parcel 2, and noticed that this incorrect default behavior issue still exists, hence this bug report. I believe the goal of As an analogy, imagine Parcel 2 ignores sass compilation errors by default, and requires you to configure |
|
I also believe type checking should be the default. Using Babel to just get rid of the type annotations and nothing else defeats the main purpose of TypeScript, which is to ensure a strongly typed codebase and every benefit that comes with it. There are also some other limitations of using Babel over TypeScript documented by the team at I should add that this would also be the proper way to get error checking on Vue files with Parcel. In the past, it has been recommended to use |
|
Our opinion was that your IDE should catch typing errors when developing and on deploy using a CI/CD service it should be a step before even starting up anything (including Parcel) to speedup the process, similar to how you'd do linting. Typing fails, don't run build/tests/... I've also been using typescript for a couple years and have never had the need to have parcel throw validation errors the IDE integration works fine for most cases. In my opinion this should never be considered a bug, it's just a different opinion. The default might change though, especially as we have full freedom as it's still alpha. I didn't know vue couldn't be typechecked using tsc. This is pretty convincing to change the default... although the spam in dev mode is pretty annoying but probably the point of having types I guess. On a positive note the validations only run after Parcel fully completed so you never have the annoying issue that you can't look at a change without fixing the types. It does however return an error in production mode so a properly configured CI/CD pipeline would not deploy... I'll flag this as an RFC, seems more fitting than question or bug. Would be cool to do a poll on this or something at some point. |
|
I'm quite confused by that position. If the official stance is that external tools should be used for handling compilation errors, why does Parcel report errors for other compilers, like sass? Sass is a superset of CSS with a compiler, much like TypeScript is a superset of JavaScript with a compiler. It seems like you're looking at TypeScript as if it's a linter instead of a separate language with separate compilation and configuration needs. I propose that TypeScript is treated as a first-class zero-configuration part of Parcel's bundler, using the real Microsoft TypeScript compiler by default, with full type checking in the bundling process. No external tools required, it's just drop in a If people want to use babel for whatever reason, that could be configured in Thank you for opening this up for dialogue so the community can comment. |
|
We have definitely improved TypeScript support greatly since Parcel 1, but we still have a long way to go as you mentioned to become a perfect zero-config tool for TypeScript based projects. (we introduced typechecking, exporting and treeshaking typings, ...) I've opened a PR to move a step closer to that ideal scenario by enabling typechecking by default, maybe it'll get merged into v2 #4025 Not entirely sure if we should use tsc by default though as it's a performance and stability concern at the moment, babel asts can be reused between babel transformer and our js-transformer which improves performance slightly. Also we've had issues with tsc due to the use of custom configs that didn't play nicely with our v1 babel transformer. |
|
I agree with @bbugh. The current behavior is a deal-breaker for me using Parcel. If I'm using Typescript, I fully expect the build to break if there is a type error. For contrast, I've been very happy with Next.js's out-of-the-box Typescript support. Just rename a file to .tsx, and you are basically good to go. Next automatically adds a tsconfig.json if it doesn't exist. I'm not sure if it uses tsc or Babel — either way it's working very well. |
I think there is some confusion between syntactic errors (your code won't parse), and semantic errors (your code has a type error). TypeScript distinguishes between the two. With other tools, Parcel reports only syntactic errors. That doesn't prevent you from having other kinds of errors (e.g. linting, test failures, etc.). I guess the question is: why would Parcel include TypeScript by default if it isn't going to include ESLint, Jest, etc.? You'd likely want those to fail your build too. So where do we draw the line? In a real CI setup, you're probably going to run a bunch of tools other than just Parcel: your package manager, your tests, your linting, etc. Is it really so hard to run And during development, you have your IDE to check your types. No need to switch to your terminal to see them. That just sounds inconvenient. So, I'm not sure I really understand why we should do that in Parcel either. |
You can't run It is therefore not trivial run type-checking on .vue files using Parcel. There's also this inconsistency: Vue templates are built with the Vue template compiler, Sass files are compiled with the Sass compiler, CoffeeScript files are built with the CoffeeScript compiler. Why is TypeScript not built with the TypeScript compiler? In reply to this:
When it comes to making a distinction between type errors and other types of errors, I'd say that types are part of the TypeScript language itself, while linting and testing are not. |
|
I think y'all are viewing it too closely based on the technical implementation instead of from the typical Typescript end-user's perspective. I view Typescript as totally different than ESLint. I view Typescript as it's own compiled language, like C for example. If a C file has a semantic type error, it won't compile and you can't even run it. That is the experience I expect with Typescript. |
It's faster. We need a Babel AST anyway, so if Babel can compile TS for us, it's faster to do it that way. That's kinda the wrong question though. The TS compiler has nothing to do with type checking. TS will happily compile files with semantic errors, just like Babel, Sass, or CoffeeScript. In fact, with Type checking is a separate task from compiling. That's done by a Validator plugin in Parcel, just like for ESLint.
I would find that incredibly annoying during development. I don't write perfect types while I'm still figuring out what to write, and I don't want that to block me trying things. That's why TS separates type checking from compiling: so you can have the best of both worlds. |
|
I can understand how some folks wouldn't want the build to break, but I think this is a small minority. At the very least, I think Parcel should have a configuration option for causing the build to break. |
I think that's where the real opinion split is. I think it's incredibly useful during development. In fact, the sole reason people use TypeScript instead of JavaScript, and indeed the reason it even exists.
It all boils down to discipline. I would say that if you're using TypeScript, you should know what your types are. If you don't know what type, then just use I would say if you're using TypeScript, you don't just type untyped code temporarily and figure out types as an afterthought. At my workplace we (and I think most programmers around the world) found that "temporary" is the most permanent thing there exists. If you don't want types, or types are just an afterthought, just use JavaScript. IDEs like VSCode will help you as much as they can even with regular JS files. All in all, I don't mind having to use config to enable type checking. It is a bit disappointing, yes, but if we are using Babel ASTs and most of the work is done for us, then I think the compromise wouldn't be too bad. I do have a couple of questions, though:
I'm not fully used to how validators work in Parcel, but would the de facto TypeScript validator able to type-check the script out of a .vue file? Also, what can we do about Babel's incompatibility with the full TypeScript spec, including no support for namespaces, const enum, legacy import/export and caret type-casting with JSX enabled? |
This is possible by adding the typescript validator plugin as we already mentioned. It builds everything and just throws an error at the end as typechecking is totally seperate from compilation like devon mentioned. I also don't really understand why you'd compare TS with C, TS works completely fine without any types. While you can't even write C without types, typescript is just a superset of JS which makes it basically a fancy linter. |
(Note that Parcel is running TSC via |
|
I agree that type checking in IDE and CI should be enough, given that there's no type-driven compilation in TS. I do find it surprising that tsconfig is ignored. I think it's very rare to not have one in a TypeScript project. Disclaimer: I don't use Parcel (yet). I came from this Reddit thread. |
|
I agree with @devongovett! It needs to as fast as possible by default (think "blazing fast"). Running full typechecks can still be done when building for production, so you won’t run into any unexpected surprises. I‘ve been using parcel 1 in every react+typescript project in the past couple of years and it always outperformed my tediously crafted webpack-configs (which is not zero-config at all, me being a webconfig noob). We currently have some >100 file projects and started migrating to CRA for some of Dans "fast refresh" goodness as it was available there first and after dabbling with Flutter and SwiftUI for a bit you will become painfully aware of those build-times... Would be interesting to see what people want to configure in tsconfig.json in a zero-config environment (besides strictness rules). |
No, that's not possible. TypeScript doesn't know how to import |
|
A couple of thoughts: Regarding the sentiment that type checking in the IDE should be enough: My experience is that it is not a thorough check (at least in VSCode). It only checks the files that you have opened, which in my case is typically a small subset of the project. There's an issue requesting them to make the error checking reflect the entire project that has been open since 2016 with 610 thumbs up, but no sign of it being addressed any time soon. I tend to agree with @bbugh that Typescript should be supported properly by default (using tsc), though it seems like a speed vs correctness issue and the trade-off should be configurable. If babel's transpilation differs in significant ways from tsc, then Typescript users might be in for a surprise when using Parcel, where they encounter these differences. (e.g. the lack of support for With regards to @DomiR 's question
The In a way this could be viewed as a case where Parcel's behaviour surprised me because it differed from tsc (in terms of how it resolves imports). But it makes sense that Parcel doesn't resolve files in the same way as tsc if one knows that Parcel doesn't use tsc and that Babel doesn't care about the tsconfig.json either. But I wasn't really aware that it was cutting corners in this way and therefore I found it to be a surprising and unintuitive experience, and so not a great thing for an out-of-the-box default. |
|
Supporting TypeScript via Babel is pretty common. Hugely popular tools like Next.js, Gatsby, Create React App, and others all do so. Has anyone looked to see if users of those tools have had negative experiences? |
In CRA we use fork-ts-checker-webpack-plugin to run TSC type checking in parallel with babel via @babel/preset-typescript. This has worked fairly well for us and I suspect we would have the same complaints as OP if we removed type checking. |
|
I believe that works exactly how @parcel/validator-typescript works. It also runs in the background to perform type checking, but both still use Babel for actual compilation. |
|
Type checking is essential and should not be optional IMO. |
|
@orta I'm going to have to completely disagree with you. A build that is a bit sluggish but has correct results is merely inconvenient. A build that is fast but has incorrect results is useless. If I wanted “as fast as possible” and didn't care if my code is correct, I wouldn't be using TypeScript.
Editors cannot show all TypeScript errors. Editors also cannot show errors that occur in files other than the one being edited.
No, it's not. Running your build system from the command line is a perfectly normal final check for the whole project. In a project using Parcel, that build system is Parcel, not |
|
I get that I'm posting in a thread that can realistically only be made up of people who disagree, but TypeScript always emits JS on purpose and has a compiler flag which you can turn on to get the workflow you're talking about ( |
|
Unless I'm misunderstanding I don't believe that's relevant, you'll still get type-checking. I personally don't care if it emits or not upon type-checking failing, only that there is type-checking and any errors are reported to me. |
|
Based on the number of people on this thread, it seems supporting TS better is something we should work on. If I were to put together a plan for how we could accomplish the goals of this thread, would anyone be willing to help us implement it? There’s a lot more to this than just a config change, eg .vue/.svelte TS checking support is a big project on its own and not something that’s currently supported even with the existing plugins. |
|
I'd be willing to help improve TypeScript support, especially with regards to Vue. In the Parcel 2 Vue transformer, TypeScript files are actually imported as separate assets from |
|
@101arrowz typechecking does not and should not happen in a transformer, it will significantly slow down building. It happens in the typescript validator https://github.com/parcel-bundler/parcel/tree/v2/packages/validators/typescript There's a lot more to typechecking in a tool like this than just calling tsc. |
|
I'm not happy with performance being put ahead of safety, but since one of Parcel's core principles is being "blazing-fast," I suppose there really isn't any other option. My point is that TypeScript users, by nature of using TS over JS, have agreed to give up the rapid prototyping and monkeypatching capabilities of pure JS for more safety, and Parcel treating TS the same as JS might help prototyping but will make development more frustrating later on. Regardless of the position the Parcel team chooses to take, the existing TS infrastructure could be improved upon, as you have mentioned, so I'll work on that for now. |
|
The reason for not doing type checking in the transformer isn’t performance, but because it’s actually impossible to do it there. Type checking requires a full graph of files. It cannot be done just on a single TS file at a time. For example, you could have imported and exported types and values. Transformer plugins in Parcel operate on individual files, as they are discovered. Type checking must be done in a Validator plugin, at the end, once the full graph is known. |
|
In order to support .vue type checking, we would need to store the TS asset that’s extracted by the transformer and somehow mark that for validation later. In the TS validator, when a .vue file is imported, we’d need to resolve that to just the TS part so that the TS compiler doesn’t need to worry about the other parts. |
|
This thread is getting very long and there's lots of different features being requested here, so I've put together three separate issues to discuss them:
Please leave your feedback for the relevant feature on these individual issues. If anyone is interested in helping to implement them, please let us know. It would be greatly appreciated. 😄 |
|
I am happy to see there are issues now to improve the TypeScript support. The lack of TypeScript full adoption in Parcel has been a barrier to entry for us. I did add the validator and that does break when running code in the "debug" mode of Parcel. |
|
For me lack of error checking on the Parcel side makes Parcel useless to use during development. The perfect use case is that Parcel watches the files, and rebundles them when changes are detected. Errors are shown in the terminal output if any are found. Without that functionality I have to run Typescript checker and Parcel bundler at the same time, and my PC begins to struggle |
|
@kuba-orlik So the initial start of parcel EDIT: Just discovered that it still doesn't support 'baseUrl' so without that Parcel just has too many oddities to not be able to use it with TypeScript projects. It supports it but only in a minimal form. |
|
For my particular setup it would be enough if:
|
Well, I came to this thread with I think, the very same great experience in mind: Typescript support in Next.js is good. So I was convinced there was type-checking in Next.js at every-level, as my day-to-day experience with it suggests. I was wrong. Next.js uses webpack with babel-plugin-transform-typescript and its caveats. So when you run Next.js in developpement mode, where things goes only through webpack, there is no type-checking and you can verify for yourself with:
On the other hand if you look at where the build code flows, you will find verifyTypeScriptSetup with this code:
At the beginning I was in favor of it because of my experience with Next.js. But it's clear that Next.js, a kind of "zero-config" project, doesn't have it when in developpement mode (and it doesn't bother me) but have it when it comes to the build (and I think it's great). So at the end of the day
I also agree with that, oh men. |
|
If someone just simply seeks a quick Add module.exports = {
presets: ['@babel/preset-env'],
}Add module.exports = {
transform: {
'^.+\\.(tsx|ts)?$': 'ts-jest',
'^.+\\.[t|j]sx?$': 'babel-jest',
},
}Add {
{
"compilerOptions": {
"module": "commonjs",
"allowJs": true,
"strict": true,
"noEmit": true,
},
"include": ["src/**/*.ts"]
}
}From ...
"scripts": {
"start": "parcel serve ./src/index.html --port 3000",
"build": "tsc --noEmit && jest && parcel build ./src/index.html",
"type-check": "tsc --noEmit --watch",
"test": "jest --watch"
},
... |
|
Hello there, I think you've goon off topic abit, let me bring it back. The point I make in my issue:
Also:
I think Parcel 2 should work the same as Parcel 1 with regard to TypeScript. |
|
@mischnic I do like some of the quotes above:
I do hope the developers listen and will switch to |
Parcel 1 didn't do typechecking either. |
|
I did notice that, but Parcel 1 used the // tsconfig.json
{
"compilerOptions": {
"jsx": "react"
}
} |
|
The default Babel config generated by Parcel 2 would include |
|
I have created the |
|
You are welcome to submit a PR. Further complaining about this issue is pointless. We've created the issues linked in my above comment to make our intent clear. If you would like to help make that happen faster, please do. |
|
At this point, I'm going to close this. Parcel is not a type checker and will probably never be one. I don't have the bandwidth to implement and maintain this but if someone wants to implement it as a third party plugin that would be great (I guess it could probably be implemented as a reporter). Otherwise, I recommend simply running |
and others
I've been following #1378 for a long time, and I'm thrilled to see Parcel 2 taking on better first-class support for TypeScript. There's currently some problems with Parcel 2 out of the box, and I didn't see any threads tracking this, so I'm making an issue.
🐛 bug report
In 2.0.0-alpha.3.2, given a very basic TypeScript project, there are three issues:
typescriptpackage is not automatically installedtsconfig.jsonare completely ignored🎛 Configuration (.babelrc, package.json, cli command)
Here's all of the files:
package.jsoncreated from two commands:yarn init -yyarn install -D parcel@v2index.htmlindex.tstsconfig.jsonto test, and it's obviously being ignored because parcel still compiles:{ ALDIFJ SLDIFJ :LEIRJ LWEIJR; }}}}} "compilerOptions": {🤔 Expected Behavior
As part of parcels "zero configuration", parcel automatically detects TypeScript and configures the project to correctly use TypeScript.
typescriptpackage should be installed automaticallytsconfig.jsonshould be read and used by whatever is compiling it, if it exists😯 Current Behavior
typescriptpackage is not automatically installedtsconfig.jsonare completely ignored💁 Possible Solution
I'm guessing one of these two potential solutions:
transformer-babelis correctly configured to behave as expected with TypeScript, extending from V2: Typescript transform support through Babel (default) and tsc #3083typescriptand@parcel/transformer-typescript(-tsc?)is automatically installed when Parcel 2 detects a.tsfile.Either one is fine, I think, as long as the TypeScript compilation actually behaves like TypeScript by default!
🔦 Context
babelfor TypeScript: V2: Typescript transform support through Babel (default) and tsc #3083💻 Code Sample
See files above
🌍 Your Environment
The text was updated successfully, but these errors were encountered: