Fix: Webpack options

[xhulz]

PR description

Thedevtool option was changed from source-map to eval. We know that this may not be the best option, however, the memory of the virtual machines was overflowing due to the large use of resources to generate the code mapping.

Documentation

• I thought about documentation and added the doc-change-required label to this PR if documentation updates are required.

[acuarica]

lgtm

[acuarica]

Hey @xhulz, thanks for taking care and sending this. Do you know why this is happening all of a sudden? Is it something coming from Truffle upstream?

[xhulz]

Hey @acuarica!

Truffle packages have a lot of dependencies, so the extension has grown a lot in size. So, when webpack starts to pack the extension, the machine's memory doesn't stop increasing and when it reaches 95% usage, it ends the process. This is because webpack creates a lot of processes trying to create the source maps. When you come back, I can show you this happening. Another option is to increase the memory of the virtual machine that we are creating inside the Action and keep the source maps.

Anyway, we need to think about a solution for this issue.

[kevinbluer]

Looks good from my side too! As an additional check, I'll do smoke test off the pre-release when it's published to the marketplace 👍 Thanks for the wrangling on this @xhulz!

[acuarica]

Thanks for the detail explanation @xhulz, super helpful!

[acuarica]

Hey, related to

• Slow loading of the Networks view #131

I've running some benchmarks to see if we can improve performance. In the list below you can see the command and the size of its output, except in the 4th command, which shows an approximation of the Activation time.

Please note, all these commands were run in a pristine environment, i.e., to set up each environment you need to run

rm -r node_modules
rm yarn.lock
yarn install

On develop

• yarn webpack:dev && ll out/src. [..] 79M [..] extension.js
• yarn webpack:prod && ll out/src. [..] 31M [..] extension.js
• yarn package. DONE Packaged: [..]/truffle-vscode-2.3.5.vsix (110 files, 10.38MB)
• code --install-extension truffle-vscode-2.3.5.vsix. Activation time 769ms

With no faker

• yarn webpack:dev && ll out/src. [..] 70M [..] extension.js
• yarn webpack:prod && ll out/src. [..] 28M [..] extension.js
• yarn package. DONE Packaged: [..]/truffle-vscode-2.3.5.vsix (110 files, 9.67MB)
• code --install-extension truffle-vscode-2.3.5.vsix. Activation time 713ms

With no faker and devtool: false in webpack.prod.js

• yarn webpack:prod && ll out/src. [..] 15M [..] extension.js
• yarn package. DONE Packaged: [..]/truffle-vscode-2.3.5.vsix (110 files, 7.6MB)
• code --install-extension truffle-vscode-2.3.5.vsix. Activation time 529ms

This shows that by removing faker we improve a little bit, but by far the major improvement is when we remove devtool.
So in summary, should we remove devtool, i.e., devtool: false, from the production bundle?

[xhulz]

Hey @acuarica,

Thanks for that :)

I've tried to bundling using devtool: false but I've got some problems to do that on Windows. Windows shut down the process every time. Have you tried creating a VSIX on Windows VM with the same Github CI setup?

[acuarica]

Not yet, but I was wondering about any potential issues we might have when removing devtool in the production bundle. Do you know why we had source-map in the first place? Maybe @michaeljohnbennett or @kevinbluer know about this.

[xhulz]

No, i don't...

[acuarica]

Have you tried creating a VSIX on Windows VM with the same Github CI setup?

No, so let's see #268

[michaeljohnbennett]

Hey, not sure about the source-map, I think it was probably a historical thing, but in reality we don't need it for debugging the packed plugin so if you can get it working to deploy and run without it, do it! 👍🏻