From 03a1f4cf6984e5ae0edb57688c8a9dd1bf16c4aa Mon Sep 17 00:00:00 2001
From: Michael Dodge <michael.dodge@vivint.com>
Date: Mon, 2 Apr 2018 18:08:44 -0600
Subject: [PATCH 1/8] First stab at SFC to npm documentation

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 200 ++++++++++++++++++++++++
 1 file changed, 200 insertions(+)
 create mode 100644 src/v2/cookbook/packaing-sfc-for-npm.md

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
new file mode 100644
index 0000000000..154f8bf544
--- /dev/null
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -0,0 +1,200 @@
+---
+title: Packaging Vue Components for npm
+type: cookbook
+order: 10
+---
+
+## Base Example
+
+Vue components by nature are meant to be re-used. This is easy when the component is only used within a single application. But how can you write a component once and use it in multiple sites/applications? Perhaps the easiest solution is via npm.
+
+By packaging your component to be shared via npm, it can be imported/required into a build process for use full-fledged web applications:
+
+```js
+import MyComponent from 'my-component';
+
+export default {
+  name: 'my-app',
+  components: {
+    MyComponent,
+  },
+  data() {
+    ...
+  },
+  ...
+}
+```
+
+Or even used via `<script>` tag in the browser directly:
+
+```html
+  <script src="https://unpkg.com/vue"></script>
+  <script src="https://unpkg.com/my-component"></script>
+  ...
+  <my-component></my-component>
+  ...
+```
+
+Not only does this help you avoid copy/pasting components around, but it also allows you to give back to the Vue community!
+
+## Why Shouldn't I Share .vue Files Directly?
+
+Vue already allows components to be written as a single file. Because a Single File Component (SFC) is already just one file, you might ask:
+
+> "Why can't people use my .vue file directly? Isn't that the simplest way to share components?"
+
+It's true, you could share .vue files directly, and as long as the [Vue build](https://vuejs.org/v2/guide/installation.html#Explanation-of-Different-Builds) being used contains the Vue compiler, that would be enough. But this excludes anyone who wishes to use the component directly in a browser via `<script>` tag, anyone who uses a runtime-only build, or a build process which doesn't understand what to do with .vue files.
+
+By packaging your SFC for distribution via npm, your component can be shared in a way which is ready to use directly in the browser as well as in most build processes!
+
+## Packaging Components for npm
+
+For the purposes of this section, assume the following file structure:
+
+```
+package.json
+build/
+   rollup.config.json
+src/
+   wrapper.js
+   my-component.vue
+dist/
+```
+
+### How does npm know which version to serve to a browser/build process?
+
+The package.json file used by npm really only requires one version (`main`), but as it turns out, we aren't limited to that. By specifying 2 additional versions (`module` and `unpkg`) we can hit that sweet spot and older build processes, newer ES6 compatible ones, and eve browsers directly! A sample package.json would look like this:
+
+```json
+{
+  "name": "my-component",
+  "version": "1.2.3",
+  "main": "dist/my-component.umd.js",
+  "module": "dist/my-component.esm.js",
+  "unpkg": "dist/my-component.min.js",
+  ...
+}
+```
+
+When webpack 2+, Rollup, or other modern build tools are used, they will pick up on the `module` build. Legacy build tools would use the `main` build, and the `unpkg` build can be used directly in browsers. The [unpkg](https://unpkg.com) cdn automatically uses this when someone enters the URL for your module into their service!
+
+### How do I make multiple versions of my component?
+
+There is no need to write your module multiple times. It is possible to prepare all 3 versions of your module in one step, in a matter of seconds. The example here uses [Rollup](https://rollupjs.org) due to its minimal configuration, but similar configuration is possible with other build tools. The package.json `scripts` section can be updated with a single entry for each build target, and a more generic `build` script that runs them all in one pass. The sample package.json file now looks like this:
+
+```json
+{
+  "name": "my-component",
+  "version": "1.2.3",
+  "main": "dist/my-component.umd.js",
+  "module": "dist/my-component.esm.js",
+  "unpkg": "dist/my-component.min.js",
+  "scripts": {
+    "build": "npm run build:browser && npm run build:es && npm run build:umd",
+    "build:umd": "rollup --config build/rollup.config.js --format umd --file dist/my-component.umd.js",
+    "build:es": "rollup --config build/rollup.config.js --format es --file dist/my-component.esm.js",
+    "build:browser": "rollup --config build/rollup.config.js --format iife --file dist/my-component.min.js"
+  },
+  "devDependencies": {
+    "rollup": "^0.57.1",
+    "rollup-plugin-vue": "^3.0.0",
+    "rollup-plugin-buble": "^0.19.2",
+    "vue": "^2.5.16",
+    "vue-template-compiler": "^2.5.16",
+    ...
+  },
+  ...
+}
+```
+
+That is all that is required in package.json to get up and running. Now, all that is needed is a small wrapper to export/auto-install the actual SFC, plus a mimimal Rollup configuration, and we're set!
+
+### What does my packaged component look like?
+
+Depending on how your component is being used, it needs to be exposed as either a CommonJS/UMD javascript module, an ES6 javascript module, or in the case of a `<script>` tag, it will be automatically loaded into Vue via `Vue.use(...)` so it's immediately available to the page. This is accomplished by a simple wrapper.js file which handles the module export and auto-install. That wrapper, in its entirety, looks like this:
+
+```js
+// Import vue component
+import component from './my-component.vue';
+
+// Declare install function executed by Vue.use()
+export function install(Vue) {
+	if (install.installed) return;
+	install.installed = true;
+	Vue.component('my-component', component);
+}
+
+// Create module definition for Vue.use()
+const plugin = {
+	install,
+};
+
+// Auto-install when vue is found (eg. in browser via <script> tag)
+let GlobalVue = null;
+if (typeof window !== 'undefined') {
+	GlobalVue = window.Vue;
+} else if (typeof global !== 'undefined') {
+	GlobalVue = global.Vue;
+}
+if (GlobalVue) {
+	GlobalVue.use(plugin);
+}
+
+// To allow use as module (npm/webpack/etc.) export component
+export default component;
+```
+
+Notice the first line directly imports your SFC, and the last line exports it unchanged. As indicated by the comments in the rest of the code, the wrapper provides an `install` function for Vue, then attempts to detect Vue and automatically install the component. With 90% of the work done, it's time to sprint to the finish!
+
+### How do I configure the Rollup build?
+
+With the package.json `scripts` section ready and the SFC wrapper in place, all that is left is to ensure Rollup is properly configured. Fortunately, this can be done with a small 16 line rollup.config.js file:
+
+```js
+import vue from 'rollup-plugin-vue'; // Handle .vue SFC files
+import buble from 'rollup-plugin-buble'; // Transpile/polyfill with reasonable browser support
+export default {
+    input: 'build/wrapper.js', // Path relative to package.json
+    output: {
+        name: 'MyComponent',
+        exports: 'named',
+    },
+    plugins: [
+        vue({
+            css: true, // Dynamically inject css as a <style> tag
+            compileTemplate: true, // Explicitly convert template to render function
+        }),
+        buble(), // Transpile to ES5
+    ],
+};
+```
+
+This sample config file contains the minimum settings to package your SFC for npm. There is room for customization, such as extracting CSS to a separate file, using a CSS preprocessor, uglifying the JS output, etc.
+
+Also, it is worth noting the `name` given the component here. This is a PascalCase name that the component will be given, and should correspond with the kebab-case name used elsewhere throughout this recipe.
+
+### Will this replace my current development process?
+
+The configuration here is not meant to replace the development process that you currently use. If you currently have a webpack setup with hot module reloading (HMR), keep using it! If you're starting from scratch, feel free to install [Vue CLI 3](https://github.com/vuejs/vue-cli/), which will give you the whole HMR experience config free:
+
+```bash
+vue serve --open src/my-component.vue
+```
+
+In other words, do all of your development in whatever way you are comfortable. The things outlined in this recipe are more like 'finishing touches' than a full dev process.
+
+## When to Avoid this Pattern
+
+Packaging SFCs in this manner might not be a good idea in certain scenarios. This recipe doesn't go into detail on how the components themselves are written. Some components might provide side effects like directives, or extend other libraries with additional functionality. In those cases, you will need to evaluate whether or not the changes required to this recipe are too extensive.
+
+In addition, pay attention to any dependencies that your SFC might have. For example, if you require a third party library for sorting or communication with an API, Rollup might roll those packages into the final code if not properly configured. To continue using this recipe, you would need to configure Rollup to exclude those files from the output, then update your documentation to inform your users about these dependencies.
+
+## Alternative Patterns
+
+At the time this recipe was written, Vue CLI 3 was itself in beta. This version of the CLI comes with a built-in `library` build mode, which creates CommonJS and UMD versions of a component. This might be adequate for your use cases, though you will still need to make sure your package.json file points to `main` and `unpkg` properly. Also, there will be no ES6 `module` output unless that capability is added to the CLI before its release or via plugin.
+
+The process here is the result of what was learned looking at other vue modules which have already been published by the greater vue community. The reason for the recipe was because there was a lack of well documented patterns for preparing a component for npm.
+
+## Acknowledgements
+
+This recipe is the result of a lightning talk given by [Mike Dodge](https://twitter.com/mgdodgeycode) at VueConf.us in March 2018. He has published a utility to npm which will quickly scaffold a sample SFC using this recipe. You can download the utility, [vue-sfc-rollup](https://www.npmjs.com/package/vue-sfc-rollup), from npm. You can also [clone the repo](https://github.com/mgdodge/vue-sfc-rollup) and customize it to fill your needs.
\ No newline at end of file

From 13df2d7adc1d7019b9733c33b3289939b65fd253 Mon Sep 17 00:00:00 2001
From: Michael Dodge <michael.dodge@vivint.com>
Date: Mon, 9 Apr 2018 22:51:09 -0600
Subject: [PATCH 2/8] Clean up sample code, clarify .vue usage with SSR builds

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 40 +++++++++++++++++--------
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
index 154f8bf544..eeda752d42 100644
--- a/src/v2/cookbook/packaing-sfc-for-npm.md
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -14,14 +14,10 @@ By packaging your component to be shared via npm, it can be imported/required in
 import MyComponent from 'my-component';
 
 export default {
-  name: 'my-app',
   components: {
     MyComponent,
   },
-  data() {
-    ...
-  },
-  ...
+  // rest of the component
 }
 ```
 
@@ -37,15 +33,15 @@ Or even used via `<script>` tag in the browser directly:
 
 Not only does this help you avoid copy/pasting components around, but it also allows you to give back to the Vue community!
 
-## Why Shouldn't I Share .vue Files Directly?
+## Can't I Just Share .vue Files Directly?
 
 Vue already allows components to be written as a single file. Because a Single File Component (SFC) is already just one file, you might ask:
 
 > "Why can't people use my .vue file directly? Isn't that the simplest way to share components?"
 
-It's true, you could share .vue files directly, and as long as the [Vue build](https://vuejs.org/v2/guide/installation.html#Explanation-of-Different-Builds) being used contains the Vue compiler, that would be enough. But this excludes anyone who wishes to use the component directly in a browser via `<script>` tag, anyone who uses a runtime-only build, or a build process which doesn't understand what to do with .vue files.
+It's true, you could share .vue files directly, and as long as the [Vue build](https://vuejs.org/v2/guide/installation.html#Explanation-of-Different-Builds) being used contains the Vue compiler, that would be enough. For example, string concatenation is used as an optimization in the SSR build, so the .vue file might be preferred in this scenario (see [Packaging Components for npm > SSR Usage](#SSR-Usage) for details). But this excludes anyone who wishes to use the component directly in a browser via `<script>` tag, anyone who uses a runtime-only build, or a build process which doesn't understand what to do with .vue files.
 
-By packaging your SFC for distribution via npm, your component can be shared in a way which is ready to use directly in the browser as well as in most build processes!
+Properly packaging your SFC for distribution via npm enables your component to be shared in a way which is ready to use directly in the browser as well as in most build processes!
 
 ## Packaging Components for npm
 
@@ -63,7 +59,7 @@ dist/
 
 ### How does npm know which version to serve to a browser/build process?
 
-The package.json file used by npm really only requires one version (`main`), but as it turns out, we aren't limited to that. By specifying 2 additional versions (`module` and `unpkg`) we can hit that sweet spot and older build processes, newer ES6 compatible ones, and eve browsers directly! A sample package.json would look like this:
+The package.json file used by npm really only requires one version (`main`), but as it turns out, we aren't limited to that. We can address the most common use cases by specifying 2 additional versions (`module` and `unpkg`), and provide access to the .vue file itself using the `browser` field. A sample package.json would look like this:
 
 ```json
 {
@@ -72,11 +68,26 @@ The package.json file used by npm really only requires one version (`main`), but
   "main": "dist/my-component.umd.js",
   "module": "dist/my-component.esm.js",
   "unpkg": "dist/my-component.min.js",
+  "browser": {
+    "./sfc": "src/my-component.vue"
+  },
   ...
 }
 ```
 
-When webpack 2+, Rollup, or other modern build tools are used, they will pick up on the `module` build. Legacy build tools would use the `main` build, and the `unpkg` build can be used directly in browsers. The [unpkg](https://unpkg.com) cdn automatically uses this when someone enters the URL for your module into their service!
+When webpack 2+, Rollup, or other modern build tools are used, they will pick up on the `module` build. Legacy applications would use the `main` build, and the `unpkg` build can be used directly in browsers. In fact, the [unpkg](https://unpkg.com) cdn automatically uses this when someone enters the URL for your module into their service!
+
+### SSR Usage
+
+You might have noticed something interesting - browsers aren't going to be using the `browser` version! That's because this field is actually intended to allow authors to provide [hints to bundlers](https://github.com/defunctzombie/package-browser-field-spec#spec) which in turn create their own packages for client side use. With a little creativity, this field allows us to map an alias to the .vue file itself. For example:
+
+```js
+import MyComponent from 'my-component/sfc'; // Note the '/sfc'
+```
+
+Compatible bundlers see the `browser` definition in package.json and translate requests for `my-component/sfc` into `my-component/src/my-component.vue`, resulting in the original .vue file being used instead. Now the SSR process can use the string concatenation optimizations it needs to for a boost in performance.
+
+> Note: When using .vue components directly, pay attention to any type of pre-processing required by `script` and `style` tags. These dependencies will be passed on to users. Consider providing 'plain' SFCs to keep things as light as possible.
 
 ### How do I make multiple versions of my component?
 
@@ -89,11 +100,14 @@ There is no need to write your module multiple times. It is possible to prepare
   "main": "dist/my-component.umd.js",
   "module": "dist/my-component.esm.js",
   "unpkg": "dist/my-component.min.js",
+  "browser": {
+    "./sfc": "src/my-component.vue"
+  },
   "scripts": {
-    "build": "npm run build:browser && npm run build:es && npm run build:umd",
+    "build": "npm run build:umd && npm run build:es && npm run build:unpkg",
     "build:umd": "rollup --config build/rollup.config.js --format umd --file dist/my-component.umd.js",
     "build:es": "rollup --config build/rollup.config.js --format es --file dist/my-component.esm.js",
-    "build:browser": "rollup --config build/rollup.config.js --format iife --file dist/my-component.min.js"
+    "build:unpkg": "rollup --config build/rollup.config.js --format iife --file dist/my-component.min.js"
   },
   "devDependencies": {
     "rollup": "^0.57.1",
@@ -121,7 +135,7 @@ import component from './my-component.vue';
 export function install(Vue) {
 	if (install.installed) return;
 	install.installed = true;
-	Vue.component('my-component', component);
+	Vue.component('MyComponent', component);
 }
 
 // Create module definition for Vue.use()

From 3c8e4e3b105e4b8215005412f5c054a27ac3ffa8 Mon Sep 17 00:00:00 2001
From: Michael Dodge <michael.dodge@vivint.com>
Date: Tue, 10 Apr 2018 10:18:43 -0600
Subject: [PATCH 3/8] Run build tasks in parallel, fix dependency order

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
index eeda752d42..5949a24648 100644
--- a/src/v2/cookbook/packaing-sfc-for-npm.md
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -104,15 +104,15 @@ There is no need to write your module multiple times. It is possible to prepare
     "./sfc": "src/my-component.vue"
   },
   "scripts": {
-    "build": "npm run build:umd && npm run build:es && npm run build:unpkg",
+    "build": "npm run build:umd & npm run build:es & npm run build:unpkg",
     "build:umd": "rollup --config build/rollup.config.js --format umd --file dist/my-component.umd.js",
     "build:es": "rollup --config build/rollup.config.js --format es --file dist/my-component.esm.js",
     "build:unpkg": "rollup --config build/rollup.config.js --format iife --file dist/my-component.min.js"
   },
   "devDependencies": {
     "rollup": "^0.57.1",
-    "rollup-plugin-vue": "^3.0.0",
     "rollup-plugin-buble": "^0.19.2",
+    "rollup-plugin-vue": "^3.0.0",
     "vue": "^2.5.16",
     "vue-template-compiler": "^2.5.16",
     ...

From 0d5f7308fbb270b8bd27fd9848433a85f34dad4d Mon Sep 17 00:00:00 2001
From: mgdodge <mgdodge@hotmail.com>
Date: Thu, 12 Apr 2018 08:04:18 -0600
Subject: [PATCH 4/8] Backtick all instances of .vue, minor edits for clarity

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
index 5949a24648..c285a3532b 100644
--- a/src/v2/cookbook/packaing-sfc-for-npm.md
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -8,7 +8,7 @@ order: 10
 
 Vue components by nature are meant to be re-used. This is easy when the component is only used within a single application. But how can you write a component once and use it in multiple sites/applications? Perhaps the easiest solution is via npm.
 
-By packaging your component to be shared via npm, it can be imported/required into a build process for use full-fledged web applications:
+By packaging your component to be shared via npm, it can be imported/required into a build process for use in full-fledged web applications:
 
 ```js
 import MyComponent from 'my-component';
@@ -33,15 +33,15 @@ Or even used via `<script>` tag in the browser directly:
 
 Not only does this help you avoid copy/pasting components around, but it also allows you to give back to the Vue community!
 
-## Can't I Just Share .vue Files Directly?
+## Can't I Just Share `.vue` Files Directly?
 
 Vue already allows components to be written as a single file. Because a Single File Component (SFC) is already just one file, you might ask:
 
-> "Why can't people use my .vue file directly? Isn't that the simplest way to share components?"
+> "Why can't people use my `.vue` file directly? Isn't that the simplest way to share components?"
 
-It's true, you could share .vue files directly, and as long as the [Vue build](https://vuejs.org/v2/guide/installation.html#Explanation-of-Different-Builds) being used contains the Vue compiler, that would be enough. For example, string concatenation is used as an optimization in the SSR build, so the .vue file might be preferred in this scenario (see [Packaging Components for npm > SSR Usage](#SSR-Usage) for details). But this excludes anyone who wishes to use the component directly in a browser via `<script>` tag, anyone who uses a runtime-only build, or a build process which doesn't understand what to do with .vue files.
+It's true, you can share `.vue` files directly, and anyone using a [Vue build](https://vuejs.org/v2/guide/installation.html#Explanation-of-Different-Builds) containing the Vue compiler can consume it immediately. Also, the SSR build uses string concatenation as an optimization, so the `.vue` file might be preferred in this scenario (see [Packaging Components for npm > SSR Usage](#SSR-Usage) for details). However, this excludes anyone who wishes to use the component directly in a browser via `<script>` tag, anyone who uses a runtime-only build, or build processes which don't understand what to do with `.vue` files.
 
-Properly packaging your SFC for distribution via npm enables your component to be shared in a way which is ready to use directly in the browser as well as in most build processes!
+Properly packaging your SFC for distribution via npm enables your component to be shared in a way which is ready to use everywhere!
 
 ## Packaging Components for npm
 
@@ -59,7 +59,7 @@ dist/
 
 ### How does npm know which version to serve to a browser/build process?
 
-The package.json file used by npm really only requires one version (`main`), but as it turns out, we aren't limited to that. We can address the most common use cases by specifying 2 additional versions (`module` and `unpkg`), and provide access to the .vue file itself using the `browser` field. A sample package.json would look like this:
+The package.json file used by npm really only requires one version (`main`), but as it turns out, we aren't limited to that. We can address the most common use cases by specifying 2 additional versions (`module` and `unpkg`), and provide access to the `.vue` file itself using the `browser` field. A sample package.json would look like this:
 
 ```json
 {
@@ -79,15 +79,15 @@ When webpack 2+, Rollup, or other modern build tools are used, they will pick up
 
 ### SSR Usage
 
-You might have noticed something interesting - browsers aren't going to be using the `browser` version! That's because this field is actually intended to allow authors to provide [hints to bundlers](https://github.com/defunctzombie/package-browser-field-spec#spec) which in turn create their own packages for client side use. With a little creativity, this field allows us to map an alias to the .vue file itself. For example:
+You might have noticed something interesting - browsers aren't going to be using the `browser` version! That's because this field is actually intended to allow authors to provide [hints to bundlers](https://github.com/defunctzombie/package-browser-field-spec#spec) which in turn create their own packages for client side use. With a little creativity, this field allows us to map an alias to the `.vue` file itself. For example:
 
 ```js
 import MyComponent from 'my-component/sfc'; // Note the '/sfc'
 ```
 
-Compatible bundlers see the `browser` definition in package.json and translate requests for `my-component/sfc` into `my-component/src/my-component.vue`, resulting in the original .vue file being used instead. Now the SSR process can use the string concatenation optimizations it needs to for a boost in performance.
+Compatible bundlers see the `browser` definition in package.json and translate requests for `my-component/sfc` into `my-component/src/my-component.vue`, resulting in the original `.vue` file being used instead. Now the SSR process can use the string concatenation optimizations it needs to for a boost in performance.
 
-> Note: When using .vue components directly, pay attention to any type of pre-processing required by `script` and `style` tags. These dependencies will be passed on to users. Consider providing 'plain' SFCs to keep things as light as possible.
+> Note: When using `.vue` components directly, pay attention to any type of pre-processing required by `script` and `style` tags. These dependencies will be passed on to users. Consider providing 'plain' SFCs to keep things as light as possible.
 
 ### How do I make multiple versions of my component?
 
@@ -125,7 +125,7 @@ That is all that is required in package.json to get up and running. Now, all tha
 
 ### What does my packaged component look like?
 
-Depending on how your component is being used, it needs to be exposed as either a CommonJS/UMD javascript module, an ES6 javascript module, or in the case of a `<script>` tag, it will be automatically loaded into Vue via `Vue.use(...)` so it's immediately available to the page. This is accomplished by a simple wrapper.js file which handles the module export and auto-install. That wrapper, in its entirety, looks like this:
+Depending on how your component is being used, it needs to be exposed as either a [CommonJS/UMD]https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc#c33a) javascript module, an [ES6 javascript](https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc#4f5e) module, or in the case of a `<script>` tag, it will be automatically loaded into Vue via `Vue.use(...)` so it's immediately available to the page. This is accomplished by a simple wrapper.js file which handles the module export and auto-install. That wrapper, in its entirety, looks like this:
 
 ```js
 // Import vue component
@@ -207,8 +207,6 @@ In addition, pay attention to any dependencies that your SFC might have. For exa
 
 At the time this recipe was written, Vue CLI 3 was itself in beta. This version of the CLI comes with a built-in `library` build mode, which creates CommonJS and UMD versions of a component. This might be adequate for your use cases, though you will still need to make sure your package.json file points to `main` and `unpkg` properly. Also, there will be no ES6 `module` output unless that capability is added to the CLI before its release or via plugin.
 
-The process here is the result of what was learned looking at other vue modules which have already been published by the greater vue community. The reason for the recipe was because there was a lack of well documented patterns for preparing a component for npm.
-
 ## Acknowledgements
 
-This recipe is the result of a lightning talk given by [Mike Dodge](https://twitter.com/mgdodgeycode) at VueConf.us in March 2018. He has published a utility to npm which will quickly scaffold a sample SFC using this recipe. You can download the utility, [vue-sfc-rollup](https://www.npmjs.com/package/vue-sfc-rollup), from npm. You can also [clone the repo](https://github.com/mgdodge/vue-sfc-rollup) and customize it to fill your needs.
\ No newline at end of file
+This recipe is the result of a lightning talk given by [Mike Dodge](https://twitter.com/mgdodgeycode) at VueConf.us in March 2018. He has published a utility to npm which will quickly scaffold a sample SFC using this recipe. You can download the utility, [vue-sfc-rollup](https://www.npmjs.com/package/vue-sfc-rollup), from npm. You can also [clone the repo](https://github.com/mgdodge/vue-sfc-rollup) and customize it.

From 4fd4ed3570124522ea87172bde0947501d5eab73 Mon Sep 17 00:00:00 2001
From: mgdodge <mgdodge@hotmail.com>
Date: Thu, 12 Apr 2018 08:06:19 -0600
Subject: [PATCH 5/8] Fix typo on link

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
index c285a3532b..3c2708cf20 100644
--- a/src/v2/cookbook/packaing-sfc-for-npm.md
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -125,7 +125,7 @@ That is all that is required in package.json to get up and running. Now, all tha
 
 ### What does my packaged component look like?
 
-Depending on how your component is being used, it needs to be exposed as either a [CommonJS/UMD]https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc#c33a) javascript module, an [ES6 javascript](https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc#4f5e) module, or in the case of a `<script>` tag, it will be automatically loaded into Vue via `Vue.use(...)` so it's immediately available to the page. This is accomplished by a simple wrapper.js file which handles the module export and auto-install. That wrapper, in its entirety, looks like this:
+Depending on how your component is being used, it needs to be exposed as either a [CommonJS/UMD](https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc#c33a) javascript module, an [ES6 javascript](https://medium.freecodecamp.org/javascript-modules-a-beginner-s-guide-783f7d7a5fcc#4f5e) module, or in the case of a `<script>` tag, it will be automatically loaded into Vue via `Vue.use(...)` so it's immediately available to the page. This is accomplished by a simple wrapper.js file which handles the module export and auto-install. That wrapper, in its entirety, looks like this:
 
 ```js
 // Import vue component

From b384983575f5eb68b9badf61bf583763e3282d8a Mon Sep 17 00:00:00 2001
From: Michael Dodge <michael.dodge@vivint.com>
Date: Wed, 2 May 2018 12:44:29 -0600
Subject: [PATCH 6/8] Update url to vue-sfc-rollup utility in acknowledgements

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
index 5949a24648..d49fedb5b0 100644
--- a/src/v2/cookbook/packaing-sfc-for-npm.md
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -211,4 +211,4 @@ The process here is the result of what was learned looking at other vue modules
 
 ## Acknowledgements
 
-This recipe is the result of a lightning talk given by [Mike Dodge](https://twitter.com/mgdodgeycode) at VueConf.us in March 2018. He has published a utility to npm which will quickly scaffold a sample SFC using this recipe. You can download the utility, [vue-sfc-rollup](https://www.npmjs.com/package/vue-sfc-rollup), from npm. You can also [clone the repo](https://github.com/mgdodge/vue-sfc-rollup) and customize it to fill your needs.
\ No newline at end of file
+This recipe is the result of a lightning talk given by [Mike Dodge](https://twitter.com/mgdodgeycode) at VueConf.us in March 2018. He has published a utility to npm which will quickly scaffold a sample SFC using this recipe. You can download the utility, [vue-sfc-rollup](https://www.npmjs.com/package/vue-sfc-rollup), from npm. You can also [clone the repo](https://github.com/team-innovation/vue-sfc-rollup) and customize it to fill your needs.
\ No newline at end of file

From d90dd1683fd550332d5f64639c2cdf81903cc4f4 Mon Sep 17 00:00:00 2001
From: Michael Dodge <michael.dodge@vivint.com>
Date: Mon, 21 May 2018 12:53:49 -0600
Subject: [PATCH 7/8] Fix order, other edits suggested by @sdras

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
index 3c1de9a214..bbb93fb19b 100644
--- a/src/v2/cookbook/packaing-sfc-for-npm.md
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -1,7 +1,7 @@
 ---
 title: Packaging Vue Components for npm
 type: cookbook
-order: 10
+order: 12
 ---
 
 ## Base Example
@@ -79,7 +79,7 @@ When webpack 2+, Rollup, or other modern build tools are used, they will pick up
 
 ### SSR Usage
 
-You might have noticed something interesting - browsers aren't going to be using the `browser` version! That's because this field is actually intended to allow authors to provide [hints to bundlers](https://github.com/defunctzombie/package-browser-field-spec#spec) which in turn create their own packages for client side use. With a little creativity, this field allows us to map an alias to the `.vue` file itself. For example:
+You might have noticed something interesting - browsers aren't going to be using the `browser` version. That's because this field is actually intended to allow authors to provide [hints to bundlers](https://github.com/defunctzombie/package-browser-field-spec#spec) which in turn create their own packages for client side use. With a little creativity, this field allows us to map an alias to the `.vue` file itself. For example:
 
 ```js
 import MyComponent from 'my-component/sfc'; // Note the '/sfc'
@@ -87,11 +87,11 @@ import MyComponent from 'my-component/sfc'; // Note the '/sfc'
 
 Compatible bundlers see the `browser` definition in package.json and translate requests for `my-component/sfc` into `my-component/src/my-component.vue`, resulting in the original `.vue` file being used instead. Now the SSR process can use the string concatenation optimizations it needs to for a boost in performance.
 
-> Note: When using `.vue` components directly, pay attention to any type of pre-processing required by `script` and `style` tags. These dependencies will be passed on to users. Consider providing 'plain' SFCs to keep things as light as possible.
+<p class="tip">Note: When using `.vue` components directly, pay attention to any type of pre-processing required by `script` and `style` tags. These dependencies will be passed on to users. Consider providing 'plain' SFCs to keep things as light as possible.</p>
 
 ### How do I make multiple versions of my component?
 
-There is no need to write your module multiple times. It is possible to prepare all 3 versions of your module in one step, in a matter of seconds. The example here uses [Rollup](https://rollupjs.org) due to its minimal configuration, but similar configuration is possible with other build tools. The package.json `scripts` section can be updated with a single entry for each build target, and a more generic `build` script that runs them all in one pass. The sample package.json file now looks like this:
+There is no need to write your module multiple times. It is possible to prepare all 3 versions of your module in one step, in a matter of seconds. The example here uses [Rollup](https://rollupjs.org) due to its minimal configuration, but similar configuration is possible with other build tools - more details on this decision can be found [here](https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c). The package.json `scripts` section can be updated with a single entry for each build target, and a more generic `build` script that runs them all in one pass. The sample package.json file now looks like this:
 
 ```json
 {
@@ -121,7 +121,9 @@ There is no need to write your module multiple times. It is possible to prepare
 }
 ```
 
-That is all that is required in package.json to get up and running. Now, all that is needed is a small wrapper to export/auto-install the actual SFC, plus a mimimal Rollup configuration, and we're set!
+<p class="tip">If you have an existing package.json file, it will likely contain a lot more than this one does. The file used in this recipe merely illustrates a starting point. Also, the <i>packages</i> listed in devDependencies (not their versions) are the minimum requirements for rollup to create the three separate builds (umd, es, and unpkg) mentioned. As newer versions become available, they should be updated as necessary.</p>
+
+Our changes to package.json are complete. Next, we need a small wrapper to export/auto-install the actual SFC, plus a mimimal Rollup configuration, and we're set!
 
 ### What does my packaged component look like?
 

From a45233d7ad18d340b5d3774381175a50adb3ff91 Mon Sep 17 00:00:00 2001
From: Michael Dodge <michael.dodge@vivint.com>
Date: Thu, 24 May 2018 14:00:01 -0600
Subject: [PATCH 8/8] Additional explanation about sfc-to-npm recipe
 package.json

---
 src/v2/cookbook/packaing-sfc-for-npm.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/v2/cookbook/packaing-sfc-for-npm.md b/src/v2/cookbook/packaing-sfc-for-npm.md
index bbb93fb19b..90cbf4b5f8 100644
--- a/src/v2/cookbook/packaing-sfc-for-npm.md
+++ b/src/v2/cookbook/packaing-sfc-for-npm.md
@@ -57,6 +57,8 @@ src/
 dist/
 ```
 
+<p class="tip">Throughout this document, references are made to the package.json file listed above. The file used in these examples was generated by hand, and will include the minimum configuration required for the discussion/task at hand. It is likely your own package.json file will contain a lot more than is listed here.</p>
+
 ### How does npm know which version to serve to a browser/build process?
 
 The package.json file used by npm really only requires one version (`main`), but as it turns out, we aren't limited to that. We can address the most common use cases by specifying 2 additional versions (`module` and `unpkg`), and provide access to the `.vue` file itself using the `browser` field. A sample package.json would look like this:
@@ -121,7 +123,7 @@ There is no need to write your module multiple times. It is possible to prepare
 }
 ```
 
-<p class="tip">If you have an existing package.json file, it will likely contain a lot more than this one does. The file used in this recipe merely illustrates a starting point. Also, the <i>packages</i> listed in devDependencies (not their versions) are the minimum requirements for rollup to create the three separate builds (umd, es, and unpkg) mentioned. As newer versions become available, they should be updated as necessary.</p>
+<p class="tip">Remember, if you have an existing package.json file, it will likely contain a lot more than this one does. This merely illustrates a starting point. Also, the <i>packages</i> listed in devDependencies (not their versions) are the minimum requirements for rollup to create the three separate builds (umd, es, and unpkg) mentioned. As newer versions become available, they should be updated as necessary.</p>
 
 Our changes to package.json are complete. Next, we need a small wrapper to export/auto-install the actual SFC, plus a mimimal Rollup configuration, and we're set!