While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/is intended for code that can run as-issrc/is intended for code that needs to be manipulated before it can be usedbuild/is for any scripts or tooling needed to build your projectdist/is for compiled modules that can be used with other systems.bin/is for any executable scripts, or compiled binaries used with, or built from your module.test/is for all of your project/module's test scriptsunit/is a sub-directory for unit testsintegration/is a sub-directory for integration testsenv/is for any environment that's needed for testingdoc/documentation files, include aREADME.mdin the root and reference docs there.examples/use case examples
The difference in using lib vs src should be:
libif you can use node'srequire()directlysrcif you can not, or the file must otherwise be manipulated before use
If you are committing copies of module/files that are from other systems, the use of (lib|src)/vendor/(vendor-name)/(project-name)/ is suggested.
If you have scripts/tools that are needed in order to build your project, they should reside in the build directory. Examples include scripts to fetch externally sourced data as part of your build process. Another example would be using build/tasks/ as a directory for separating tasks in a project.
If your project/module is to be built for use with other platforms (either directly in the browser), or in an AMD system (such as require.js), then these outputted files should reside under the dist directory.
It is recommended to use a (module)-(version).(platform).[min].js format for the files that output into this directory. For example foo-0.1.0.browser.min.js or foo-0.1.0.amd.js.
The bin folder is for any system modules your package will use and/or generate.
- The compiled
node_gypoutput for your module's binary code. - Pre-compiled platform binaries
package.json/binscripts for your module
Wow, sorry... don't even remember writing this, lol... been a long while.
When I wrote this, was mostly considering stand alone libraries. If you're writing an application, I tend to use
./srcfor the app's source code... keeping most of the other conventions... for stylesheets, I tend to favor them with the components they're used with, and globals with any higher level wrapper components.For cmd/bat files, yeah, I'd put them largely in bin or build respectively. I tend to favor using the package.json scripts section with npm, and have the respective JS files where they belong. I use shelljs a lot for command scripts.
as to BDD, /src/feature/FEATURE_SECTION is what I tend to use for applications, stand alone libraries a bit different.