The size of the node_modules folder in a project is really big.

[patmill]

On my machines, they are appearing as around 233 megs, but I've seen reports of others up to 400 megs or more.
Note that the bundles that are downloaded to the browser are fairly small, but the build footprint is quite large.

The first thing is to attempt to rationalize the versions of some packages. There are ~63 megs of projects included at the root as well as in sub node_modules folders. For example, gulp-typescript includes typescript, as well as it being at the top level. The top asks for 1.8.9, and gulp-typescript is requesting 1.8.7

[vvolodin]

And some modules used (on multiple levels) are really outdated.

[wictorwilen]

@vvolodin - that's also the nature of node.js, in order to get that fixed Microsoft and/or we (the community) has to tell those module owners to update their modules. Contact them, create PR's etc.

[mauricionr]

when i run npm dedupe my machine take a lot of time to resolve the duplicated dependencies

[vvolodin]

@wictorwilen Yes, exactly my point, that's why I'm contacting this project owners asking to update their modules :) Project made with this generator references React 0.14.8 and office-ui-fabric-react 0.36.0

[SPDoctor]

If you are seeing folder sizes of 500MB + and deeply nested folders, please check your version of npm - should be something like 3.10.7. If npm -v reports 2.something you need to upgrade: npm -g install npm@next

[mike-morr]

Can we please remove the bug field? This may be an expectation that needs to be set more appropriately, but I think changing the project to accommodate for this is a huge mistake. The sp-pnp-js project is 120mb and it is a relatively small library. This is just the reality of this ecosystem. I would mark it "By Design". I think the workbench should be considered a required dependency. There is a lot of value in that 220mb. @patmill @wictorwilen @SPDoctor

[vvolodin]

Definitely an ecosystem thing. You are not meant to ever copy, move or upload these files.

[patmill]

There are bugs in here as well that need to be fixed. typescript and phantom are showing up multiple times, so that's 30+ megs of stuff that should get cleaned up. I don't think we'll get to 10 megs or anything silly like that, but we can certainly do better than we currently are.

[wictorwilen]

I did a little research here, I have about 220-250 Mb of node_modules, depending on which framework I choose in the generator setup.

But I noticed this:

• As @patmill says, the phantomjs-prebuilt takes about 20% of this space and it's in two different versions. Once used by sp-build-core-tasks (v2.1.12) and once used by gulp-core-build-karma (2.1.6). Both are modules that you Microsoft has control over and can align.
• In general the testing parts (karma, phantomjs) has a lot of dependencies; could include the testing stuff be optional?
• These modules are used by modules that you, Microsoft, has control over in multiple versions - which can be deduped, here's just a few:
  • json5 (0.4.0, 0.5.0)
  • loader-utils (0.2.15, 0.2.13)
  • object-assign (4.1.0, 4.0.1)
  • gulp-core-build-typescript
  • tslint
  • typescript (1.8.7, 1.8.9)
  • lodash (many different versions), and each of these has about 2k files. Not much to do for you, but make sure that you use the same version in your stuff
• under sp-client-preview/lib/local/clientSideWebParts/docs - there's a couple of megs of images from the DK times
• office-ui-fabric-react - another module you can control, why not remove some of those images in the dist folder. This one also have many thousands of files
• bufferutil and *utf-8-validate' has large pdb files
• sourcemaps in @microsoft modules - do we really need them in the "final" build?
• all of the gulp-core-build-XXX all depend on different gulp-core-build modules and they all contains test coverage files, typings and source maps that really shouldn't have to be in those packages.

A non scientific test when removing the stuff above I get down to 165 Mb - it might be hard to get below that, unless you start to rely on global modules.

[vvolodin]

Pretty please, don't remove sourcemaps.

[wictorwilen]

@vvolodin yea, it's a give and take - but do you really need sourcemaps for SPFx? Given that all this is being open sourced, you can pull it down and build a "debug" version if you really need to.