Noissue - bundle in one operation to ensure no races

README.md

 Shared Adblock Plus UI code
 ===========================
 
 The user interface elements defined in this repository will be used by various
 Adblock Plus products like Adblock Plus for Firefox. Their functionality can be
 tested within this repository, even though they might not work exactly the same
 as they will do in the final product.
 
 Installing dependencies
 -----------------------
@@ skipping 86 matching lines @@
   * ensure `browserify` uses `--node` and `--no-bundle-external` flags
   * point at the entry point, and output in the top level folder
 
 Accordingly, this is what happens with the `bundle:desktop-options`:
 
 ```sh
 # the && operator ensure each step is executed only
 # if the previous one didn't produce an error
 eslint ./js/**/*.js &&
 # browserify doesn't offer a way to prefix with text
-# the file is hence created with eslint disabled and a warning
-echo '/* eslint-disable */// BUNDLED FILE' > ./desktop-options.js &&
+# the file is hence created with eslint disabled plus
 # browserify take an entry point and bundle all its required files
 # outputting the result into ./desktop-options.js
-browserify --node --no-bundle-external js/desktop-options.js >> ./desktop-options.js
+bash -c 'echo "/* eslint-disable */
+$(browserify --node --no-bundle-external
+  js/desktop-options.js)">./desktop-options.js'
 ```

[Thomas Greiner, 2018/03/07 13:48:11]

Suggestion: Maybe we shouldn't include any code here. Otherwise we always have
to keep it in sync with the actual code in package.json.

Do you think it's worth the duplication?

[a.giammarchi, 2018/03/07 14:09:00]

my idea is that the README explains what happens in specific package.json
scripts entries but there's no need whatsoever to duplicate this per each new
entry because they will all look the same.

So, if your concern is about needing to update the README if we change the
scripts, then maybe you are right, we don't need such duplication.

However, not everyone is super familiar with bash so that expanded with few
comments might help understanding it.

But then again, as explanation of how bash works, this is indeed not exhaustive
at all.

Maybe we can drop it as soon as we need to add new scripts and/or we change
something?

[Thomas Greiner, 2018/03/07 14:25:48]

That can go hand-in-hand with my other comment because if we split off the
actual build logic into separate files we could document all of those
implementation details inline as we do with all of our other code.

We could then focus on the purpose and how to use each individual command here
in the README.

 
 For a new bundle, i.e. `mobile-options.js`, simply use the same procedure
 but swap the `desktop-options` file/script name with `mobile-options`.
 
 The main `bundle` script should include each sub-bundle operation.
 
 Watching
 --------
 
 While developing, it is convenient to bundle automatically
@@ skipping 70 matching lines @@
   errors when adding new filters on the options page
 * `blockedURLs`: a comma-separated list of URLs that should be considered
   blocked (necessary to test the check for blocked scripts in sharing buttons).
 * `downloadStatus`: sets downloadStatus parameter for filter lists, can be used
   to trigger various filter list download errors
 * `platform=chromium`: shows the opt-out for the developer tools panel
 * `showNotificationUI=true`: simulates user having opted-out of notifications
 
 
 [crowdin]: https://crowdin.com