CLI 3.0 build size | Typescript vs ES6

[YvanDaSilva]

Version

3.0.0-beta.6

Reproduction link

https://jsfiddle.net/50wL7mdz/184064/

Steps to reproduce

Create 2 vue projects.
Project A (vue create vue-cli-ts):

1. Go custom then -> Select everything including TS
2. yarn build / npm build
3. Whatch the resulting build info

Project B (vue create vuecli-no-ts) :

1. Go custom then -> Select everything except TS
2. yarn build / npm build
3. Watch the resulting build info

What is expected?

Builds shouldn't be extremely different in size. (There will always be a margin -> TS transpilation to JS)

What is actually happening?

There is more than 30% size increase for TS based vendor bundle.
There is more than 10% size increase for TS based app bundle

---

Project A (vue-cli-ts)

  File                                      Size             Gzipped

  dist/js/vendor.9e0a13bd.js                128.90 kb        43.41 kb
  dist/js/app.a6133549.js                   15.08 kb         8.88 kb
  dist/service-worker.js                    0.95 kb          0.54 kb
  dist/precache-manifest.8c3336142c1938a    0.44 kb          0.22 kb
  1dcd7c0151a065fd3.js
  dist/css/app.dee3710a.css                 0.42 kb          0.26 kb

Project B (vuecli-no-ts)

  File                                      Size             Gzipped

  dist/js/vendor.1bc00b6a.js                96.04 kb         32.72 kb
  dist/js/app.9d221347.js                   13.60 kb         8.37 kb
  dist/service-worker.js                    0.95 kb          0.54 kb
  dist/precache-manifest.1ab260dc03549dc    0.44 kb          0.22 kb
  6a5b3a24943ce681a.js
  dist/css/app.cb8f9cda.css                 0.42 kb          0.26 kb

Notes:

• It would be interesting to test this with a larger project (which I don't have)
• It might just be a transpilation behavior and there is verry little to do about it
• It might be a config issue

Leaving this issue here to be get more info and test later on.

[LinusBorg]

Go custom then -> Select everything including TS

Does that inlcude the option for class component syntax?

That adds an additional lib to the bundle, plus boilerplate for the tranpiled decorator & class syntax effectively.

PS: Had you provided a repository with the exact project your created, I would not have to ask.

[YvanDaSilva]

Yes, it does (select everything). You're right, but you can also admit that if you use yarn (cache) it will take you less time to test all options than me to create all repos as they are just the default CLI create command. In fact creating a test for this wouldn't be that dumb ;) for future analyses.

[LinusBorg]

You're right, but you can also admit that if you use yarn (cache) it will take you less time to test all options than me to create all repos as they are just the default CLI create command.

You can certainly look at it this way, but that view is a bit too narrow for me:

1. We, the maintainers have to run reproductions a lot more often than you, the writer of this issue, have to create them (unless you are a daily contributor of issues to a lot of repsositories, in which case: cudos to you). Every bit of time saved for us results in more improvements to the software we create for you, and helps keep us sane. So your calulation isn't correct in when looking at the project as a whole instead of your isolated issue.

2. A github repository (or in simpler cases besides vue-cli, a simple jsfiddle) is the only way to be sure that you can reproduce exactly the same environment the author of the issue had when running into the reported problem. In fact, we have had the problem of reporters forgetting/missing to share vital parts of the context (without any bad intent or lazyness - often reporters can't know what might be important) that we simply made it a rule to not look into issues that don't come with a runnable reproduction, because we burnt so much time going back and forth with people in order to get the information that a reproduction would have made available to us immediatly.

To put it a bit bluntly: If setting up a small reproduction isn't worth your time, the issue can't be that important to you (and probably anyone else), so we probably can ignore it and invest the limited time and resources we have into issues that are set up in a way that allows us to quickly solves them and improve the project we work on for free.

Your issue right here is by far not the worst example of this, mind you, but we have rules for a reason. and putting cheeky messages about how the rules don't apply to your issue in a fake reproduction link isn't really helping.

I think this can be closed.

[YvanDaSilva]

@LinusBorg I perfectly understand your point of view and respect all the work and effort you put into the project.

Now:

1. I was merely suggesting a test to follow the behavior, if I had time I'll gladly provide you with a PR.
2. You have "enhancement" and "feature requests" in your issues, however your web page allowing to create an issue doesn't allow neither of those. Hence this bug, report which isn't a bug.
3. With all my respect. My cheeky message was only the reply to yours (See your PS).

This issue was merely to point the fact, that following my exact steps, the bundle sizes where different and there might or might not be something to investigate.

Don't take it personally, but you just went way out of your way to explain something to me that makes 0 progress in any way to this issue or to the project. But I appreciate the time you took and read your words properly. And I note that the next time, I'll provide you the necessaries because it's what you require.

Now, you can leave this closed (in fact you should), I'm way too busy for this, living on the same time zone as you, look at when I replied to you. Or/And you can put this conflict aside, and create a new issue as enhancement to follow the bundle sizes progress as an enhancement.

Thanks for your work and dedication anyway.

A great day to you, best regards,