Separate dev and prod files

[ray-print]

These commits separate prod and src files into dedicated directories and get rid of the .dev.js extensions.
Prod files are minified for production builds and not minified for dev builds. (excluding the CSS file which is always minified, I'll fix that soon)
To match standard directory structure the prod directory should be labeled 'dist', but that is a breaking change so it should not be made until the next major version bump.
Let me know if these changes are okay or you'd prefer a different structure :)
I didn't realize when I started this that Bower simply copies files, which means we can't just .gitignore prod files. The alternative is to have a separate release branch and have Bower point to that. Both options aren't great :( .
Can we publish on npm? I can do the actual commands and any required set-up and add you as an owner if that is easiest (and remove myself after publishing if you'd prefer). I think it's really important to support NPM because it's such a big player in Javascript package management right now.

[victorjonsson]

These are all great improvements indeed!

Let's say that we decide to versionize the production files in the same repository, located in a directory named dist. What would then be the next steps?

1. Build, and versionize, prod files in form-validator until release of 2.3.0
2. Prior to release of 2.3.0 update the path references on cdnjs and the main property in bower.json

If you take care of the npm publishing stuff and add me as an owner that would be great!

[ray-print]

What kind of versioning system is the project currently using?
If it follows semantic versioning, then we'd have to bump the version
number to 3.0.0 when we made a breaking change.
Other than that, sounds fine to me. There were one or two other fixes
on this branch (CSS minification, adding "Auto-generated" to the prod
file banner) that I have to finish up, but I wanted to makes sure you
were okay with the changes first. After that, I'll work on the npm
thing. (Closely related to that are ensuring that the project will
work out of the box with Browserify/Webpack. It'd also be nice if
there were some way to load modules server-side, but that's a ways
off.)

On 2/23/16, Victor Jonsson notifications@github.com wrote:

These are all great improvements indeed!

Let's say that we decide to versionize the production files in the same
repository, located in a directory named dist. What would then be the next
steps?

1. Build, and versionize, prod files in form-validator until release of
   2.3.0
2. Prior to release of 2.3.0 update the path references on cdnjs and the
   main property in bower.json

If you take care of the npm publishing stuff and add me as a owner that
would be great!

---

Reply to this email directly or view it on GitHub:
#389 (comment)

[victorjonsson]

Could you elaborate on why the directory needs to be renamed from form-validator to dist. Is it only because it's the current convention and that people therefore expects the source files to be located in a directory named dist, or is it more than that? Does the current directory name prevent the use of this library in tools such as webpack and browserify?

[ray-print]

The main reason I had was that I think it should be immediately clear
what files are source code, for developers to work with, and what
files are production code, which is produced by the build tool and
then used in production. I don't think the name change is very
important, or that the exact name matters (I'm 90% sure we can
integrate with whatever we like regardless of the directory name).
"Dist" is common and easily recognizable so I chose that. But it's not
a big deal. Let me know if you want me to revert the change or remove
any comments in the code referencing a future change.

On 2/25/16, Victor Jonsson notifications@github.com wrote:

Could you elaborate on why the directory needs to be renamed from
form-validator to dist. Is it only because it's the current standard and
that people therefore expect the source files to be located in a directory
named dist, or is it more than that? Does the current name prevent the use
of this library in tools such as webpack and browserify?

---

Reply to this email directly or view it on GitHub:
#389 (comment)

[victorjonsson]

No that's okey. I just don't feel we need to rush the changing of the name.

[ray-print]

I agree, no rush