bbugh commented 4 years ago

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:

the typescript package is not automatically installed
settings in tsconfig.json are completely ignored
typescript errors are silently ignored and compiled anyway

🎛 Configuration (.babelrc, package.json, cli command)

Here's all of the files:

package.json created from two commands:
- yarn init -y
- yarn install -D parcel@v2

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>My First Parcel App</title>
    <script src="index.ts"></script>
  </head>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>

index.ts

console.log("Hello, von Nuemann!")
const failMe: BadType = 5; // this should fail, but it compiles

optionally, I added a junk tsconfig.json to 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.

TypeScript compilation or validation should fail by default when there are type errors
typescript package should be installed automatically
tsconfig.json should be read and used by whatever is compiling it, if it exists

😯 Current Behavior

the typescript package is not automatically installed
settings in tsconfig.json are completely ignored
typescript errors are silently ignored and compiled anyway

💁 Possible Solution

I'm guessing one of these two potential solutions:

The current default transformer-babel is correctly configured to behave as expected with TypeScript, extending from #3083
typescript and @parcel/transformer-typescript(-tsc?) is automatically installed when Parcel 2 detects a .ts file.

Either one is fine, I think, as long as the TypeScript compilation actually behaves like TypeScript by default!

🔦 Context

Seems to have started in this PR that defaults to babel for TypeScript: https://github.com/parcel-bundler/parcel/pull/3083
Type checking seems to have been merged, but it's not happening: https://github.com/parcel-bundler/parcel/pull/3232

💻 Code Sample

See files above

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-alpha.3.2
Node	v10.15.3
npm/Yarn	1.21.1
Operating System	Mac 10.14.6

DeMoorJasper commented 4 years ago

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}

bbugh commented 4 years ago

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 parcelrc is to only be used in situations where Parcel's intelligent defaults do not cover a use case. I suggest that properly supporting TypeScript's type checking should be the default behavior, not behavior that requires extra configuration.

As an analogy, imagine Parcel 2 ignores sass compilation errors by default, and requires you to configure parcelrc to actually show errors. That wouldn't make much sense either!

danielegarciav commented 4 years ago

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 ts-jest, which means that people who rely on TypeScript won't get what they are used to in other projects.

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 tsc --noEmit, but that command does not work on .vue files.

DeMoorJasper commented 4 years ago

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.

bbugh commented 4 years ago

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 ts file and the appropriate libraries are added and run.

If people want to use babel for whatever reason, that could be configured in parcelrc. Not every project that uses TypeScript will want to use Babel, especially because Babel doesn't support the full TypeScript language spec.

Thank you for opening this up for dialogue so the community can comment.

DeMoorJasper commented 4 years ago

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.

flybayer commented 4 years ago

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.

devongovett commented 4 years ago

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?

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 tsc to check types? Why should it be part of bundling?

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.

danielegarciav commented 4 years ago

Is it really so hard to run tsc to check types?

You can't run tsc on .vue files. These files were specifically made to be compiled by a bundler (some standalone tools have been proposed, but none have come to fruition yet), which would then pass the script section to whatever compiler is set.

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:

That doesn't prevent you from having other kinds of errors

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.

flybayer commented 4 years ago

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.

devongovett commented 4 years ago

Why is TypeScript not built with the TypeScript compiler?

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 transpileModule (which is what we'd use), TSC does no type checking at all (it cannot, without cross file analysis).

Type checking is a separate task from compiling. That's done by a Validator plugin in Parcel, just like for ESLint.

If a C file has a semantic type error, it won't compile and you can't even run it

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.

flybayer commented 4 years ago

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.

danielegarciav commented 4 years ago

If a C file has a semantic type error, it won't compile and you can't even run it

I would find that incredibly annoying during development.

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.

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.

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 any. At least you have documented to other fellow developers that you don't know what type some variable truly is yet.

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:

That's done by a Validator plugin in Parcel, just like for ESLint.

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?

DeMoorJasper commented 4 years ago

At the very least, I think Parcel should have a configuration option for causing the build to break.

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.

mischnic commented 4 years ago

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?

(Note that Parcel is running TSC via transpileModule, which has limitations as well)

Kinrany commented 4 years ago

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.

DomiR commented 4 years ago

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).

devongovett commented 4 years ago

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?

No, that's not possible. TypeScript doesn't know how to import .vue files. Parcel cannot magically make it understand them. All the validator plugin does is call the TypeScript language service API to perform type checking. From there, the TS compiler handles your code just like tsc on the command line.

uglycoyote commented 4 years ago

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 const enum is one language feature mentioned in @mischnic's link which Babel apparently does not support.) I'm not sure how these descrepancies between Babel and Typescript have evolved or will evolve over time. I would think that for Typescript users the least surprising behaviour for Parcel would be to use tsc, and therefore it's a sensible default. Users willing to sacrifice correctness to build faster should be able to configure that.

With regards to @DomiR 's question

Would be interesting to see what people want to configure in tsconfig.json in a zero-config environment (besides strictness rules).

The baseUrl property comes to mind. I was a bit shocked and disappointed to find out that Parcel was unable resolve some of my valid import statements because it did not obey the baseUrl parameter in tsconfig.json.. See my recent issue #4014 and the much older issue #202 regarding this.

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.

devongovett commented 4 years ago

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?

ianschmitz commented 4 years ago

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.

devongovett commented 4 years ago

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.

moltar commented 4 years ago

Type checking is essential and should not be optional IMO.

phaux commented 4 years ago

I like to be able to run type checking, linting, formatting or bundling as a separate command. If I wanted to do everything at once I would just run tsc && eslint && prettier && parcel which I usually do in my prepublish script

hammypants commented 4 years ago

For me, personally, Parcel + Typescript is unusable, especially under the guise of "zero configuration," with the way it currently works. But I see the other points as well. Better documentation around the expectations of how Parcel + TS is intended to work wouldn't help either-- had to comb many issues to get here.

argv-minus-one commented 4 years ago

If you don't run the real TypeScript compiler, you don't support TypeScript, and it's misleading to claim otherwise on your website.

I see that this is due to a performance concern, but that is no excuse. Correctness is always more important than performance. A slow, correct build is merely annoying; a fast, incorrect build is useless.

phaux commented 4 years ago

I disagree. I think that a bundler should only do the bundling and the fact that you can transform TS into JS without any typechecking (unlike Elm, Rust, etc) is a big win. If you want to do both, just run tsc && parcel build or enable appropriate parcel plugin, but it shouldn't be the default.

samhh commented 4 years ago

There's no point in using TypeScript if you're not going to leverage the type safety it offers you, and you can't meaningfully leverage it without the compiler checking your project as you develop.

Parcel's tagline in this repo is:

Blazing fast, zero configuration web application bundler

It looks like the heart of the issue is that we have to choose between the two; we can't be "blazing fast" with type-checking, and we surely aren't a "zero-configuration [...] bundler" for TypeScript without type-checking given it's something virtually all TypeScript users will want enabled in tandem with their bundling.

Therefore it clearly needs to be configurable, and all that's left is to determine which of Parcel's goals is most important. In my opinion that's zero-configuration, particularly given that small projects won't notice the performance penalty that type-checking entails.

There is a secondary question that remains regarding Parcel's support being via Babel, which doesn't behave as well as the official TypeScript compiler.

SeekDaSky commented 4 years ago

I'd like to weight in and say that I use parcel (incredible work by the way) for the "zero configuration" part. I can setup a project in a matter of minutes and understand what's going on (unlike webpack). I don't care for a few seconds of improvement if the code compiled is wrong.

I can totally understand your stance, and a choice might be given to the developer if he wants a faster compilation (huge complex projects is the use case I think of)

But the lack of typecheck by default is really unintuitive for me , I use Typescript mainly for it and I find the faster default to be counterproductive.

uglycoyote commented 4 years ago

I find myself agreeing with points from both sides on this issue. I work exclusively with Typescript and My main reasons for jumping off the Webpack bandwagon and onto Parcel were 1) speed and 2) ease of getting up and running.

I was really amazed when I started using Parcel at the response time, when saving my code and seeing things update in the browser in less than a second, where I was used to having it take tens of seconds using Webpack (using a plugin that built Typescript with tsc). Even though I ideologically fall into the "correctness is more important" camp, in practice I don't know that I would actually want to sacrifice the speed of bundling to ensure that tsc is always run.

I am sort of bothered though that I was unaware for a long time that it was using babel and not tsc. I just assumed tsc was the way all typescript was built, and didn't really know that just running it through babel to strip the annotations was even a possibility. I feel like this should be clearer. I feel like there should be a warning message with that. It does say clearly in the Typescript page that Parcel doesn't do type checking, but maybe I just missed that sentence or didn't fully understand what it meant.

I also feel like, although the goal of Parcel is to be "zero configuration", that should mean that the best defaults are chosen automatically, and not necessarily that it's not configurable.

I would suggest that if you are building Typescript using babel, the bundler could output Warning: Bundling Typescript without using tsc. To enable type-checking, use "parcelTypescriptBuildMethod: tsc" in your package.json. Or, on the other hand if you are using tsc, it could output Note: Build speed will be slower because type checking is enabled. For improved performance, use "parcelTypescriptBuildMethod: babel" in your package.json. (I'm inventing an imaginary config option here)

There's a clear trade off here between speed and checking. Typescript Correctness people are arguing that it's not a valid Typescript build without the checking. Fast Bundler people are arguing, that Parcel is a bundler and that's not the bundler's job, so do it out-of-band if you want it.

Maybe with the "fork-ts-checker" plugin mentioned earlier, one can have their cake and eat it too (fast bundling with type checking on the side), but I haven't tried that. If that is the best of both worlds for typescript users, maybe that should be the default, zero-configuration setup: a third mode called parcelTypescriptBuildMethod: babelWithBackgroundTypecheck should be the default?

mischnic commented 4 years ago

To give an overview over the current implementation:

Your syntax parcelTypescriptBuildMethod: babelWithBackgroundTypecheck corresponds to a .parcelrc with

{
"extends": "@parcel/config-default",
"validators": {
"*.{ts,tsx}": ["@parcel/validator-typescript"]
}
}

parcelTypescriptBuildMethod: babel is currently the default

for parcelTypescriptBuildMethod: tsc

{
"extends": "@parcel/config-default",
"transformers": {
"*.{ts,tsx}": ["@parcel/transformer-typescript-tsc"]
}
}

uglycoyote commented 4 years ago

@mischnic Thanks, that's very informative, and I think that information, along with a short blurb about the trade-offs involved would make excellent material for a section in the https://parceljs.org/typeScript.html page

mischnic commented 4 years ago

in the parceljs.org/typeScript.html page

(rather: in the page about Typescript in the Parcel 2 docs)

argv-minus-one commented 4 years ago

I'm shocked that this is even being seriously discussed. For me, coming from a Java background, compiling without type checking is unthinkably reckless.

den-t commented 4 years ago

parcelTypescriptBuildMethod: babelWithBackgroundTypecheck corresponds to a .parcelrc with
{
  "extends": "@parcel/config-default",
  "validators": {
    "*.{ts,tsx}": ["@parcel/validator-typescript"]
  }
}

Could this be made default? Any reasons against?

ptitjes commented 4 years ago

Hi folks, I tried to implement ~ paths resolution with parcel v2 ala https://parceljs.org/typeScript.html#baseurl-and-paths. But parcel complains it cannot resolve my ~/file.ts imports. Is this supposed to work in parcel v2 yet ? Should I open an issue ?

I can provide a reproduction repo.

Here is what my project tree looks like:

- package.json
- tsconfig.json
- .parcelrc
- src/
    - index.html
    - index.ts
    - file.ts

Here is my .parcelrc:

{
  "extends": "@parcel/config-default",
  "transformers": {
    "*.{ts,tsx}": ["@parcel/transformer-typescript-tsc"],
    "*.svg": ["@parcel/transformer-svgo"]
  },
  "validators": {
    "*.{ts,tsx}": ["@parcel/validator-typescript"]
  }
}

and my tsconfig.json:

{
  "compileOnSave": false,
  "compilerOptions": {
    "sourceMap": true,
    "allowSyntheticDefaultImports": true,
    "declaration": false,
    "jsx": "react",
    "esModuleInterop": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "strict": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es5",
    "lib": [
      "es2018",
      "dom"
    ],
    "baseUrl": "./src",
    "paths": {
      "~/*": [
        "./*"
      ],
      "@cabasvert/data": [
        "../../data/src"
      ]
    }
  },
  "include": [
    "scripts",
    "src"
  ],
  "exclude": [
    "dist",
    "node_modules"
  ]
}

And I get:

@parcel/resolver-default: Cannot find module '~/file' from '/home/didier/Code/parcel2-ts-test/src'

Cristy94 commented 4 years ago

I tried the @parcel/validator-typescript but I get this error:

ℹ Server running at http://localhost:1234
√ Built in 8.19s
Installing @parcel/validator-typescript...
@parcel/package-manager: Added 1 packages via npm
TypeError: input.replace is not a function
    at markdownParser (\node_modules\@parcel\markdown-ansi\lib\markdown-ansi.js:20:17)
    at prettyDiagnostic (\node_modules\@parcel\utils\lib\prettyDiagnostic.js:32:167)
    at writeDiagnostic (\node_modules\@parcel\reporter-cli\lib\CLIReporter.js:142:37)
    at _report (\node_modules\@parcel\reporter-cli\lib\CLIReporter.js:117:13)
    at Object.report (\node_modules\@parcel\reporter-cli\lib\CLIReporter.js:172:5)
    at ReporterRunner.report (\node_modules\@parcel\core\lib\ReporterRunner.js:77:31)
    at process._tickCallback (internal/process/next_tick.js:68:7)

If I run build again it works, but I don't get any TS errors in the console, it builds successfully (when there actually are errors).

uglycoyote commented 4 years ago

I finally got around to actually trying Parcel 2 with Typescript and I'm finding that I just get a bunch of errors from the Babel transpilation that I did not used to get from Parcel 1, and it's code that is clean as far as tsc is concerned. (things along the lines of @parcel/transformer-babel: myfile.tsx: Missing class properties transform. on a fairly ordinary class member variable declaration). Initial googling on this appeared to indicate that I needed an additional plugin for babel to solve this, but installing it did not change the situation. I'll probably file a separate issue about this later if I cannot figure out the solution.

I thought I would mention this here though in the context of the conversation of this discussion about whether Parcel should be running babel or tsc by default on Typescript files, since it appears to be an example of where babel is handling my files quite differently than tsc, for some reason that i don't understand, and I feel that if this happens to a lot of Typescript users it will probably turn them off from wanting to use Parcel.

mischnic commented 4 years ago

Initial googling on this appeared to indicate that I needed an additional plugin for babel to solve this, but installing it did not change the situation. I'll probably file a separate issue about this later if I cannot figure out the solution.

This is because @babel/preset-typescript does not include the @babel/plugin-proposal-class-properties plugin (I'm don't know why they made that decision). You have to add it to your babelrc manually, installing is not enough

mischnic commented 4 years ago

This is because @babel/preset-typescript does not include the @babel/plugin-proposal-class-properties plugin

Actually, this is because @babel/preset-env's shippedProposals doesn't include the syntax.

shunia commented 4 years ago

I'm a long time Typescript user and a long time Parcel user.

It's confusing that I have to learn how to work with babel, because my bundler force me to. Typescript is compiling and type checking everything just fine, I can not find any reason to use babel.

I think it should be like: If people want to use babel to compile their Typescript projects, use .parcelrc to do so. If people don't know any of that, they should be just fine with their current setup (with Typescript to do the work).

Which means, use Typescript to compile should be default.

rinick commented 4 years ago

I'm also a long time parcel 1 user that works mostly with typescript. And this is my experience:

I tried to upgrade one of my projects to parcel 2, spent 30 minutes, couldn't build it correctly, reverted back to 1.x. after 6 months, did this again to see if newer version is easier, spent 30 minutes. still couldn't get it to work.

The reason I choose to switch back to parcel 1 from parcel 2 again is the same reason I chose parcel over webpack in the first place. I don't want to spend a lot of time learning how to config the bundler.

DeMoorJasper commented 4 years ago

@rinick I'm not sure I understand there's still no need to configure Parcel, the only difference with TypeScript is that we switched from tsc to Babel for performance and stability reasons. You would only configure Parcel if you need tsc for any reason, although Babel and tsc support the same features as far as I know (except for a couple features we would need to opt out in tsc anyway because we cannot support them anyway)

You can always open up an issue or discussion if you think there's a bug or have a question on how anything works in Parcel 2 compared to Parcel 1. There's also a migration page on the docs site https://v2.parceljs.org/getting-started/migration/

rinick commented 4 years ago

@DeMoorJasper Thanks for the reply yes, I had a custom babelrc but didn't define @babel/preset-typescript there, that fixes my development build for parcel2

but still, it doesn't work in production mode. scope-hoisting is causing issues, I have to use --no-scope-hoist

mattrossman commented 4 years ago

@DeMoorJasper What I'm hearing is that to use type checking with parcel you need to either:

configure your IDE (e.g. VSCode only checks open files by default)
configure a CI/CD pipeline
configure a .parcerc and .tsconfig

I don't believe any of these options are "zero config".

I agree with @uglycoyote that if parcel wants to continue with this unintuitive approach, it should at least be verbose about it.

DeMoorJasper commented 4 years ago

@mattrossman you'll have to create a tsconfig file regardless of what you/we do, we can output a default preset but that seems like a bad idea. Some users don't use JSX, some want strict typescript, some don't, ...

Creating a file with a single line doesn't really seem like that much work to turn it on. We're still a zero-config bundler, which means you don't need config for most codebases, not that there is no config.

Parcel is not an end-to-end development platform, it's a bundler, we could add linting and typechecking if we want and we kind of already did but it's opt-in as a lot of people still want a bundler to just bundle and not lint or typecheck

mattrossman commented 4 years ago

a lot of people still want a bundler to just bundle and not lint or typecheck

@DeMoorJasper Can you create a poll to back up this claim? Because looking at the emoji reactions to the comments in this issue, it seems like most people actually do want it to typecheck. I don't think including a default tsconfig is a bad idea.

DeMoorJasper commented 4 years ago

a lot of people still want a bundler to just bundle and not lint or typecheck

@DeMoorJasper Can you create a poll to back up this claim? Because looking at the emoji reactions to the comments in this issue, it seems like most people actually do want it to typecheck. I don't think including a default tsconfig is a bad idea.

I guess maybe @devongovett can do this if he wants as he owns the parcel Twitter account and a lot of followers.

mattrossman commented 4 years ago

Parcel is not an end-to-end development platform, it's a bundler

I should also point out that @devongovett's statements don't reflect this view.

From a tweet in May:

I'm going to stop describing Parcel as a "bundler". That's only one small piece of what it does. In Parcel 2, it's literally a plugin!

Parcel is an application graph. It can be a compiler, a static site generator, a documentation generator, a type checker, a linter, and more.

I guess the key word here is "can" be, it just comes down to what it "should" be by default. Hopefully he can set that poll up to let the community decide.

phaux commented 4 years ago

What I'm hearing is that to use type checking with parcel you need to either:

configure your IDE (e.g. VSCode only checks open files by default)

configure a CI/CD pipeline

configure a .parcerc and .tsconfig

I don't believe any of these options are "zero config".

You can simply run tsc && parcel instead of just parcel to get typechecking. It is zero config.

parcel-bundler / parcel

Parcel 2: TypeScript automatic zero configuration not type checking or reading tsconfig.json #4022

🐛 bug report

🎛 Configuration (.babelrc, package.json, cli command)

🤔 Expected Behavior

😯 Current Behavior

💁 Possible Solution

🔦 Context

💻 Code Sample

🌍 Your Environment