#77 - Tree shaking in samples about pnp-js-core

[patrick-rodgers]

Ok, so what does this mean? I understand "tree shaking" but what changes would we need to make? What do we need to do beyond what we have done to support this? Your example from where ever (too many threads) if I just include { add } as you suggest, how would add know the url it should have? At that moment add is just a function with no context - currently it knows its url because we have built it - how would we support that change without re-writing every method to contain full urls?

As for "We should start discussing ways to soften their landing into the world of gulp." - what are your suggestions? We have a wiki, would love to have more content there. I agree, there is a big learning curve for folks and we should do everything to help - and I am looking to the js community team to be that help.

I think the pattern we've landed on works, and we should think carefully before making changes like this.

At the risk of turning this into a debate, one issue I have with open source, which I raised at the Dev Kitchen in Brussels is that the open source community is very fickle, use grunt? pah, so 2015, use gulp, pah - you should ditch that for xyz and so on. I fear that every time a new thing bubbles to the surface, people will want to jump onto that - IMO, let's focus on the core right now and get that right. This library isn't going to be huge once bundled and minified so don't think we need to address it just yet.

As for the gulp discussion, I'll raise some issues around what we can do to help users for @patrick-rodgers to mark as "help wanted" and we can all take a bit to help one another.

[patrick-rodgers]

Unless we can frame this as an actionable issue, i.e. make these specific changes to enable "tree shaking" I'd like to close this issue and move the discussion to Yammer/gitter. We aren't trying to not support it, but to date I can't get an explanation as to what we need to do to support it. It also from what I read requires that we provide es6 modules, something I was told in another issue we can't and have to provide es5.

[mike-morr]

@tobiaswest83 I am only suggesting this for samples. Not sure this makes any sense for the lib itself, because we have to ship it in it's entirety and we have so few dependencies that I don't think it would save us enough to be worth the effort.

@patrick-rodgers We can provide es6 modules like it was before. We cannot point main at the ES modules which is how it was before. The esnext:main should point at the es6 modules. Main has to point to the es5 modules.

The only change I can see that we might have to make to the lib, is to favor the second example below. Note: I still need to confirm officially that this is accurate.

import { GetRandomNumber } from "../utils/util"; // Includes all of the util module.

import getRandomNumber from "../utils/util/getRandomNumber" // Only imports the function

I was left with the impression from the GA announcement that mobility of the SP Framework stuff is something we want to strongly encourage. Frankly, IMO this is the first time mobile is going to be usable with a good experience in SharePoint and I think we should. This makes it something we need to promote and provide guidance around.

The actionable items I see for this are.

• Discuss and decide if the gain is worth the effort. I believe it is, but I have a business need for this personally so I am biased. I have a customer with field employees using phones and ipads in remote areas with very spotty coverage. So the difference in download speeds would be very significant.
• Research the module import syntax above to see if us standardizing on the second syntax example above makes sense.
• Package ES6 libs and point only the jsnext:main at that bundle. This should be purely additive.
• Tweak existing sample using beta of Webpack 2. I think rollup is really cool, but more people are using webpack. We could re-evaluate if rollup becomes the new hotness.
• Build future samples with this built in.

Perhaps it's time to add some milestones and roadmap, I see the first 2 action items being actionable now and the rest as part of a later milestone.

[pbjorklund]

I guess packaging tools is/will be smart enough to do intelligent tree shaking the same way test coverage tools work. Makes more sense for it to trim the parts of transpiled sources that are never called.

Action should be: Build a sample that shows how this "pattern" can be implemented for packaging scenarios where bandwidth is crucial.

[pbjorklund]

For reference the footprint of one of my solutions grew by 1000% even when uglified when including sp-pnp-js in it's current state even though I just wanted to use 1 function on the web object. This is the scenario @mike-morrison is talking about.

For instance imagine that I would just want to the Locale enum which adds a hefty 7kb to the library size. How would I access just this without bundling the whole package?

[patrick-rodgers]

1000% increase by adding the minified lib at 79k? If you only need one function, or the Locale enum you can always copy and paste that code out of the library. I have often done that in the past with the CSOM library. The issue with breaking out one method on web is that we would then have to make every method understand the full url it represents. This breaks the ability to chain things together arbitrarily. Also if you are hyper concerned with size creating a direct rest call in your code will always be better than anything we can do when trying to support "tree shaking".

I did de-ref the Locale enum in the code to that it is no longer packaged in the dist files by browserify. It is still in src so people can use it with an import, but not being packaged saved a good bit.

Some reading on the jsnext:main reveals there isn't really a consensus. Here is a good discussion and they are promoting it for their own tool. This quote from here

Now, because npm normally expects CommonJS, not ES6 modules, there is an informal “jsnext:main” field that some libraries use to point to their ES6 source. Usage is not very widespread, though, so if any of your dependencies don’t use ES6 or don’t have a "jsnext:main", then you’ll need to use Rollup’s --external flag when bundling them so that it knows to ignore them.

"jsnext:main" is a nice hack, but it also brings up a host of unanswered questions, such as: which features of ES6 are supported? Is it a particular stage of recommendation for the spec, ala Babel? What about popular ES7 features that are already starting to creep into codebases that use Babel, such as async/await? It’s not clear, and I don’t think this problem will be resolved until npm takes a stance one way or the other.

To enable this we would need to another entire lib with es6 (or es2015) modules which seems like it would be confusing. What if we wait until there a more stable solution than jumping on the "new hotness" and then needing to turn around and change it several times as new things come out? Ideally we would just publish es6/2015 modules in lib and es5 in dist. The only thing stopping this is node and the current need for commonjs, correct?

[pbjorklund]

If I copy it I can't just pull the latest sp-pnp-js package and have everything instantly better. :)

My usecase was just to illustrate why it would be nice to cherrypick and just have that part pulled into the bundle. But adding 20 layers of complexity just to enable this probably isn't the right way to go right now.

I'm in favor of waiting unless someone provides an example of how it could be achieved without giving me a headache.

[patrick-rodgers]

Closing this because there is currently no npm package supported method to support this. Once we have a concrete way to support this that is less likely to change and is better defined we can revisit.