Webpack Not Allowed - Official Answer Requested


#1

Just got my extension pushed back from review with:

Your Extension contains obfuscated code (using webpack), this is not allowed.

Which is puzzling, because extensions are available using webpack and contain “obfuscated code” example. The development platform doesn’t seem level or open if some developers get special treatment or policies are unclear.

I don’t know exactly what goes on during the review process, but requiring vanilla JS limits the developer pool and even the types of extensions developers might want to create. No hard feelings, just some clarification is needed from Twitch on this.

To clarify, the following were provided with explanation for my review submission:

  • GitHub link to the public repository for the project
  • A simple, single webpack configuration file to bundle the JS and output the the three client HTML files.
  • A package.json file listing the required dependencies, and a NPM build script that outputs the identical build directory submitted for review (produces identical MD5 hash).

In short, the authored code was available in a clear and non-obfuscated form to the review process, but the submission was rejected nonetheless.

Related content:


@Kathy


How can i use webpack in twitch Extensions
IE11 support. Targeting es6 browsers only
#2

I know that Kathy was tagged here, but hopefully my answer will be of value. This post is being made to help provide a degree of transparency, and good faith for the burgeoning community of Extensions developers.

Let’s start by going back in time, to the first quarter of 2017. At that point, Twitch put out feelers within the developer community (under NDA) for parties that would be interested in working with us to develop third party web-apps that would run on Twitch (what are now called Extensions). In May, Twitch launched a limited beta exploring new interactive experiences (again Extensions under another guise). In September, Extensions were made available to everybody - all developers, and all broadcasters. These early developers weathered a lot of changes in Extensions. For that we were incredibly grateful, as it meant that in May we had a number of Extensions that were made available to a subset of broadcasters, and then again in September, there were a number of Extensions available for all broadcasters to leverage. The constant changes to Extensions endpoints and policies made developers’ lives hard. Some of the changes that came through very late, related to our policy around obfuscated code. In short, in order to support a scalable and implemented internal review process, we introduced change around the requirement for not obfuscating code. There were other policy changes that were also made close to the public release of Extensions. The problem with these changes is that it would have meant that most of the Extensions that had been developed prior to launch would have been rejected based upon the most recent policy changes. As a sign of good faith for the developers who stuck with us, we grandfathered their Extensions through the review process, in the context of policy changes that did not exist when they began their development. This grandfathering has only been extended to a small handful of individual Extensions, and is by no means an all access pass.

Reviews today only leverage uploaded assets. Upon upload, they are fed into our review system, where they are put through a number of automated checks, coupled with several manual review steps. External links, and build scripts cannot currently be ingested and incorporated into our review system. This is an area that we are actively working on improving. The challenge with the approach that you provided was that none of the source entered our review process.

I hope that this at least answers some of your questions.


#3

I understand the position, and it make sense. Perhaps an enhanced boilerplate project could be provided in the future with specified requirements that supports additional development workflows. I had to do some wonky things outside my normal project setup to get accepted that makes the development process unfun.

In the end, I’m still impressed with the platform and truly think it offers something unique to developers. Thanks for your thoughts.


#4

Can’t you still use Webpack? When you say “obfuscated code” I’d assume you mean “minified”. I suppose I can understand that. It will suck for load times, though, so I imagine a lot of dirty one liners in some extensions. Anyway, Webpack or Browserify should still be fine, right? I mean, what if you make an extension with React? It’s not expected of people write raw React code… right?


My Demo Extension Not appearing in hosted testing on my channel
#5

No, minified code should be ok as per docs. What do you mean about React? I was able to use it just fine.


#6

What do you mean by obfuscated then? Anything beyond minified has to be too troublesome some, right?

And I mention React specifically because virtually no one uses it without Webpack or Browserify, which your title suggests would be a problem.


#7

Generally this means that function names are changed to shorter versions.

function foo

and

function thisFunctionMakesCake

become function f and function t

Basically means removal of whitespace and newlines


#8

It’s my understanding that minification does ever you’ve just mentioned. Ergo unless there is an option to not shorten function names and other things the tool can’t be used…

I don’t know about Webpack but Browserify alone doesn’t minify; you’d need to use something like Uglify to do the minification. This would do the obfuscation you describe. I hope there’s an option to not shorten names because without any compression file sizes are gonna suck…


#9

To me, minification is just collapsing of white space and line breaks, it doesn’t touch the code otherwise. It’s trivial to unminimize code.

In regards to obfuscation, this means actually altering parts of the code for performance gains or sometimes security purposes. Depending on why/how the code was obfuscated, it can be very hard or impossible to read naturally.

Even without utilizing production build options, webpack may output code that reviewers find hard to read. They also don’t want you to bundle any third party libraries with your own code, because it’d be hard to read and would make verifying the integrity of those libraries difficult.

React can be used just fine without something like webpack, as can any library really. Webpack is primarily a module bundling tool (dealing with imports/exports that browsers don’t handle yet), that also has a lot of other neat plugins that can be used over tools like Gulp. Sure it’s used a ton in React, Vue, Angular, etc. but is by no means required.

Unless you are doing super crazy things or adding in lots of third party libraries, I wouldn’t sweat the file sizes. Do what you can of course, but don’t let it get in the way of creating something cool.


#10

It seems that Twitch has relaxed their requirement on obfuscated code. After many rejections, my webpack extension has finally been approved!

EDIT: After submitting a new version, without changing my build process in any way, i’ve been rejected again.

They mentioned 2 things in the review email:

To clarify, we are currently allowing Webpack, however, you must disable all obfuscation, mangling, or other options that prevent readability of code. Function names for your core code must be intact and human readable.

-My submission fulfilled those requirements. I am not using uglifyjs. The function names in the webpack output are the same as my source code. How is it okay to approve one submission, and deny the next, when they have the same webpack config?

Understand that using Webpack to combine all of your libraries and core code into one file can raise review times substantially. Keeping libraries separate from your core code allows moderators to exclude standard libraries from review and only focus on your core code for your Extension.

-All of my submissions have included a vendor.js file that contains all of my 3rd party libraries. From the very first submission i have had this separate vendor file. Like… seriously? This is just a random tip that has nothing to do with my submission.

With these two extraordinarily unhelpful suggestions that my submission already fulfilled, i have no idea how to get thru the review process, i’m back to square one. Sorry for the borderline pouting, but the developer experience has been horrid so far.

EDIT
I received a review email that states

If using several large libraries, consider excluding those from Webpack and providing them as separate files. If we can check file hashes against known standard libraries, this makes it far easier to approve those libraries.

For future readers, you’ll have to include libraries as scripts instead of imports.

As for uglifyJs, these options seem to be the best fit for the review process. This leaves the original code intact, improving it even, by removing unused code. It also gives you tree shaking.

new webpack.optimize.UglifyJsPlugin({
  compress: {
	  dead_code: true,
	  unused: true,
	  side_effects: true,
	  warnings: false
  },
  mangle: false,
  output: { beautify: true },
  sourceMap: true
}),

EDIT my extension was approved with the above webpack config.


#11

@guanzo You’d have to post a sample of your webpacked code to see if anyone might be able to help. And if you’re bundling all third party dependencies to a single vendor.js file, how are they supposed to verify the integrity of those libraries, split them out by hand? I know it’s not ideal, but I think you’ll need to piece them out separately.


closed #13