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

Add typechecking to default parcelconfig #4025

Closed
wants to merge 2 commits into from
Closed

Conversation

DeMoorJasper
Copy link
Member

↪️ Pull Request

This PR enabled TS typechecking by default. This is probably more expected behaviour than the current silent behaviour.

Related #4022

✔️ PR Todo

  • Added/updated unit tests for this change
  • Filled out test instructions (In case there aren't any unit tests)
  • Included links to related issues/PRs

@parcel-benchmark
Copy link

parcel-benchmark commented Jan 21, 2020

Benchmark Results

packages/benchmarks/kitchen-sink ✅

Timings

Description Time Difference
Cold 7.75s +107.00ms
Cached 3.90s +13.00ms

Cold Bundles

Bundle Size Difference Time Difference
dist/legacy/parcel.ff215454.webp 102.94kb +0.00b 233.00ms -16.00ms 🚀

Cached Bundles

Bundle Size Difference Time Difference
dist/legacy/parcel.ff215454.webp 102.94kb +0.00b 332.00ms -26.00ms 🚀
dist/modern/parcel.76ee4591.webp 102.94kb +0.00b 330.00ms -27.00ms 🚀
dist/legacy/index.js 520.00b +0.00b 336.00ms -27.00ms 🚀
dist/modern/index.js 453.00b +0.00b 331.00ms -26.00ms 🚀
dist/legacy/index.css 29.00b +0.00b 330.00ms -27.00ms 🚀
dist/modern/index.css 29.00b +0.00b 329.00ms -26.00ms 🚀

packages/benchmarks/react-hn ✅

Timings

Description Time Difference
Cold 11.79s +649.00ms ⚠️
Cached 3.88s +33.00ms

Cold Bundles

No bundle changes detected.

Cached Bundles

Bundle Size Difference Time Difference
dist/module/index.js 34.29kb +0.00b 12.00ms +1.00ms ⚠️
dist/main/index.js 34.27kb +0.00b 17.00ms +1.00ms ⚠️

packages/benchmarks/ak-editor ✅

Timings

Description Time Difference
Cold 3.32m +3.97s
Cached 5.99s -109.00ms

Cold Bundles

Bundle Size Difference Time Difference
dist/index.js 2.33mb +6.00b ⚠️ 1.93m +2.79s
dist/Toolbar.5c7a6fbb.js 105.61kb +0.00b 1.30m +15.44s ⚠️
dist/media-viewer.81fbeba4.js 87.54kb +0.00b 7.00s -2.00s 🚀
dist/card.c0473744.js 76.79kb +0.00b 7.00s -2.00s 🚀
dist/smartMediaEditor.25b0ed57.js 67.35kb +0.00b 58.59s -4.08s 🚀
dist/ResourcedEmojiComponent.2d80adbd.js 2.25kb +0.00b 6.94s -2.00s 🚀
dist/esm.976debcc.js 178.00b +0.00b 6.86s -1.98s 🚀
dist/dropzone.976debcc.js 177.00b +1.00b ⚠️ 1.93m +1.30m ⚠️
dist/clipboard.976debcc.js 177.00b +1.00b ⚠️ 37.32s -804.00ms
dist/browser.976debcc.js 177.00b +1.00b ⚠️ 58.59s +20.47s ⚠️
dist/editorView.976debcc.js 177.00b -1.00b 🚀 36.78s -25.89s 🚀
dist/media-card-analytics-error-boundary.976debcc.js 176.00b -5.00b 🚀 38.68s -1.24m 🚀
dist/16.976debcc.js 174.00b -5.00b 🚀 37.32s -2.09s 🚀

Cached Bundles

Bundle Size Difference Time Difference
dist/index.js 2.33mb +6.00b ⚠️ 411.00ms +35.00ms ⚠️
dist/esm.976debcc.js 176.00b +2.00b ⚠️ 160.00ms -0.00ms
dist/media-card-analytics-error-boundary.976debcc.js 176.00b +2.00b ⚠️ 159.00ms +1.00ms
dist/dropzone.976debcc.js 176.00b +2.00b ⚠️ 156.00ms +1.00ms
dist/clipboard.976debcc.js 176.00b +2.00b ⚠️ 155.00ms +1.00ms
dist/browser.976debcc.js 176.00b +2.00b ⚠️ 155.00ms +1.00ms
dist/16.976debcc.js 176.00b +2.00b ⚠️ 145.00ms -0.00ms
dist/editorView.976debcc.js 176.00b +2.00b ⚠️ 130.00ms -0.00ms

Click here to view a detailed benchmark overview.

@DeMoorJasper
Copy link
Member Author

Gonna close this...

@uglycoyote
Copy link

@DeMoorJasper it's not clear from looking at this why it was closed?

@DeMoorJasper
Copy link
Member Author

@uglycoyote it had gotten too much merge conflicts and I doubt it would've ever gotten merged. From the issue it seems there's almost just as much people who want this as don't want this

@astegmaier
Copy link
Contributor

@DeMoorJasper - I think you're referring to #4022, right? My reading of that (very long, very contentious) thread was that there were at least two issues being discussed:

  1. Whether to use tsc instead of babel to do the actual transpilation
  2. Having parcel check for typescript semantic errors by default (i.e. this PR)

It seemed like a lot of folks who were new to parcel didn't understand this distinction at first (until this comment helped clarify toward the end of the discussion).

It seems accurate to say that issue 1 was very contentious because there are some very solid performance-related reasons to prefer babel. For issue number 2, it seemed more one-sided in favor of turning on semantic checking by default (although not 100% unanimous). I'd love to see a wider discussion around this comment, which posed the question directly.

My two-cents as a heavy typescript user is that I pretty much always want to get semantic type error feedback from my build tool, so it would be great to have this be the default. This is for two main reasons:

  1. I come from a background of having used tsc, webpack (with fork-ts-webpack-checker-plugin and ts-loader) and create-react-app on various projects, all of which do this. (This is more of a habit/subjective expectation, but I suspect most of parcel's typescript users will share a similar background).
  2. As this comment points out, VSCode and other editors won't report errors on files that are not open, and don't seem likely to support this in the future.

@DeMoorJasper
Copy link
Member Author

DeMoorJasper commented Apr 18, 2020

@astegmaier You’re right opinions were very mixed. I don’t mind typechecking being the default

The main reason for closing this was merge conflicts as I have enough PRs that need rebasing and have a higher chance of getting merged soonish

@astegmaier
Copy link
Contributor

The main reason for closing this was merge conflicts as I have enough PRs that need rebasing and have a higher chance of getting merged soonish

Yeah no worries. If the discussion develops and we get everyone on board with the idea of turning this on by default, I'm happy to take care of the PR.

@uglycoyote
Copy link

uglycoyote commented Apr 19, 2020

Thanks for the replies. I didn't mean to cause a firestorm and I know there's a bit of a debate about this contentious issue on #4022, which I have replied on a few times. But I was curious because the effort to change the default behaviour was started by someone who's a primary contributor and then abruptly stopped without an explanation.

Upon reading this, since the "gonna close this" comment was one day after posting the benchmarks, It made me wonder if the performance numbers in the benchmarks are what clinched the decision to close it, but it sound like it was other issues.

I looked at the benchmarks but there were too many numbers and I didn't know what the format of the report was, I could not really tell whether they said something interesting about the performance implications of this change. I'm aware that performance is the big argument in favour of leaving it the way it was (with no use of typechecking) but had not seen any figures about what the impact of enabling typechecking was by default.

@astegmaier
Copy link
Contributor

Correct me if I'm wrong, but I don't think turning on @parcel/validator-typescript by default (what I called "issue 2" above) should impact the performance of the main build, because validators only run after the bundle graph is finished. See here:

await this.#packagerRunner.writeBundles(bundleGraph);
assertSignalNotAborted(signal);
let event = {
type: 'buildSuccess',
changedAssets: new Map(
Array.from(changedAssets).map(([id, asset]) => [
id,
assetFromValue(asset, options),
]),
),
bundleGraph: new BundleGraph(bundleGraph, options),
buildTime: Date.now() - startTime,
};
this.#reporterRunner.report(event);
await this.#assetGraphBuilder.validate();

(It's a different story for using @parcel/transformer-typescript-tsc` over babel during the transform phase - see this comment).

@devongovett
Copy link
Member

Please continue this discussion on #4022 rather than on this closed PR.

@parcel-bundler parcel-bundler locked and limited conversation to collaborators Apr 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants