<commit_before><template name="concepts">

<h1 id="concepts">Concepts</h1>

We've written our fair share of single-page JavaScript applications by hand.
Writing an entire application in one language (JavaScript) with one
data format (JSON) is a real joy.  Meteor is everything we wanted
when writing those apps.

{{> whatismeteor }}
{{> structure }}
{{> data_ }}
{{> reactivity }}
{{> livehtmltemplates }}
{{> packages_concept }}
{{> namespacing }}
{{> deploying }}
{{> packages_writing }}
</template>

<template name="whatismeteor">

{{#markdown}}

<h2 id="whatismeteor">What is Meteor?</h2>

Meteor is two things:

* A _library of packages_: pre-written, self-contained modules that
  you might need in your app.

  There are about a dozen core Meteor packages that most any app will use. Two
  examples: [`webapp`](#webapp), which handles incoming HTTP connections, and
  `templating`, which lets you make HTML templates that automatically update
  live as data changes. Then there are optional packages like `email`, which
  lets your app send emails, or the Meteor Accounts series (`accounts-password`,
  `accounts-facebook`, `accounts-ui`, and others) which provide a full-featured
  user account system that you can drop right into your app. In addition to
  these "core" packages, there are thousands of community-written packages in
  [Atmosphere](https://atmospherejs.com/), one of which might do just what you
  need.

* A _command-line tool_ called `meteor`.

  `meteor` is a build tool analogous to `make`, `rake`, or the non-visual parts
of Visual Studio. It gathers up all of the source files and assets in your
application, carries out any necessary build steps (such as compiling
[CoffeeScript](http://coffeescript.org), minifying CSS, building
[npm](https://npmjs.org/) modules, or generating source maps), fetches the
packages used by your app, and outputs a standalone, ready-to-run application
bundle. In development mode it can do all of this interactively, so that
whenever you change a file you immediately see the changes in your browser. It's
super easy to use out of the box, but it's also extensible: you can add support
for new languages and compilers by adding build plugin packages to your app.

  The key idea in the Meteor package system is that _everything should work
  identically in the browser and on the server_ (wherever it makes sense, of
  course: browsers can't send email and servers can't capture mouse events). Our
  whole ecosystem has been built from the ground up to support this.

{{/markdown}}
</template>

<template name="structure">
{{#markdown}}

<h2 id="structuringyourapp">Structuring your application</h2>

A Meteor application is a mix of client-side JavaScript that runs inside a web
browser or PhoneGap mobile app, server-side JavaScript that runs on the Meteor
server inside a [Node.js](http://nodejs.org/) container, and all the supporting
HTML templates, CSS rules, and static assets.  Meteor automates the packaging
and transmission of these different components, and it is quite flexible about
how you choose to structure those components in your file tree.

### Special Directories

By default, any JavaScript files in your Meteor folder are bundled and sent to
the client and the server. However, the names of the files and directories
inside your project can affect their load order, where they are loaded, and some
other characteristics. Here is a list of file and directory names that are
treated specially by Meteor:

- **client**

    Any directory named `client` is not loaded on the server. Similar to
    wrapping your code in `if (Meteor.isClient) { ... }`. All files loaded on
    the client are automatically concatenated and minified when in production
    mode. In development mode, JavaScript and CSS files are not minified, to
    make debugging easier.  (CSS files are still combined into a single file
    for consistency between production and development, because changing the
    CSS file's URL affects how URLs in it are processed.)


    HTML files in a Meteor application are treated quite a bit differently
    from a server-side framework.  Meteor scans all the HTML files in your
    directory for three top-level elements: `<head>`, `<body>`, and
    `<template>`.  The head and body sections are separately concatenated
    into a single head and body, which are transmitted to the client on
    initial page load.

- **server**

    Any directory named `server` is not loaded on the client. Similar to
    wrapping your code in `if (Meteor.isServer) { ... }`, except the client
    never even receives the code. Any sensitive code that you don't want served
    to the client, such as code containing passwords or authentication
    mechanisms, should be kept in the `server` directory.

    Meteor gathers all your JavaScript files, excluding anything under the
    `client`, `public`, and `private` subdirectories, and loads them into a
    Node.js server instance.  In Meteor, your server code runs in a single
    thread per request, not in the asynchronous callback style typical of Node.
    We find the linear execution model a better fit for the typical server code
    in a Meteor application.

- **public**

    All files inside a top-level directory called `public` are served as-is to
    the client. When referencing these assets, do not include `public/` in the
    URL, write the URL as if they were all in the top level. For example,
    reference `public/bg.png` as `<img src='/bg.png' />`. This is the best place
    for `favicon.ico`, `robots.txt`, and similar files.

- **private**

    All files inside a top-level directory called `private` are only accessible
    from server code and can be loaded via the [`Assets`](#assets) API. This can
    be used for private data files and any files that are in your project
    directory that you don't want to be accessible from the outside.

- **client/compatibility**

    This folder is for compatibility JavaScript libraries that rely on variables
    declared with var at the top level being exported as globals.  Files in this
    directory are executed without being wrapped in a new variable scope.  These
    files are executed before other client-side JavaScript files.

- **tests**

    Any directory named `tests` is not loaded anywhere. Use this for any local
    test code.

- **node_modules**

    For compatibility with node.js tools used alongside Meteor, any directory named
    `node_modules` is not loaded anywhere. node.js packages installed into
    `node_modules` directories will not be available to your Meteor code. Use
    `Npm.depends` in your package `package.js` file for that.

### Files outside special directories

All JavaScript files outside special directories are loaded on both the client
and the server.  That's the place for model definitions and other functions.
Meteor provides the variables [`Meteor.isClient`](#meteor_isclient) and
[`Meteor.isServer`](#meteor_isserver) so that your code can alter its behavior
depending on whether it's running on the client or the server.

CSS and HTML files outside special directories are loaded on the client only,
and cannot be used from server code.

### Example File Structure

The file structure of your Meteor app is very flexible. Here is an example layout that takes advantage of some of the special folders mentioned above.<commit_msg>Adds documentation for ignored folders<commit_after><template name="concepts">

<h1 id="concepts">Concepts</h1>

We've written our fair share of single-page JavaScript applications by hand.
Writing an entire application in one language (JavaScript) with one
data format (JSON) is a real joy.  Meteor is everything we wanted
when writing those apps.

{{> whatismeteor }}
{{> structure }}
{{> data_ }}
{{> reactivity }}
{{> livehtmltemplates }}
{{> packages_concept }}
{{> namespacing }}
{{> deploying }}
{{> packages_writing }}
</template>

<template name="whatismeteor">

{{#markdown}}

<h2 id="whatismeteor">What is Meteor?</h2>

Meteor is two things:

* A _library of packages_: pre-written, self-contained modules that
  you might need in your app.

  There are about a dozen core Meteor packages that most any app will use. Two
  examples: [`webapp`](#webapp), which handles incoming HTTP connections, and
  `templating`, which lets you make HTML templates that automatically update
  live as data changes. Then there are optional packages like `email`, which
  lets your app send emails, or the Meteor Accounts series (`accounts-password`,
  `accounts-facebook`, `accounts-ui`, and others) which provide a full-featured
  user account system that you can drop right into your app. In addition to
  these "core" packages, there are thousands of community-written packages in
  [Atmosphere](https://atmospherejs.com/), one of which might do just what you
  need.

* A _command-line tool_ called `meteor`.

  `meteor` is a build tool analogous to `make`, `rake`, or the non-visual parts
of Visual Studio. It gathers up all of the source files and assets in your
application, carries out any necessary build steps (such as compiling
[CoffeeScript](http://coffeescript.org), minifying CSS, building
[npm](https://npmjs.org/) modules, or generating source maps), fetches the
packages used by your app, and outputs a standalone, ready-to-run application
bundle. In development mode it can do all of this interactively, so that
whenever you change a file you immediately see the changes in your browser. It's
super easy to use out of the box, but it's also extensible: you can add support
for new languages and compilers by adding build plugin packages to your app.

  The key idea in the Meteor package system is that _everything should work
  identically in the browser and on the server_ (wherever it makes sense, of
  course: browsers can't send email and servers can't capture mouse events). Our
  whole ecosystem has been built from the ground up to support this.

{{/markdown}}
</template>

<template name="structure">
{{#markdown}}

<h2 id="structuringyourapp">Structuring your application</h2>

A Meteor application is a mix of client-side JavaScript that runs inside a web
browser or PhoneGap mobile app, server-side JavaScript that runs on the Meteor
server inside a [Node.js](http://nodejs.org/) container, and all the supporting
HTML templates, CSS rules, and static assets.  Meteor automates the packaging
and transmission of these different components, and it is quite flexible about
how you choose to structure those components in your file tree.

### Special Directories

By default, any JavaScript files in your Meteor folder are bundled and sent to
the client and the server. However, the names of the files and directories
inside your project can affect their load order, where they are loaded, and some
other characteristics. Here is a list of file and directory names that are
treated specially by Meteor:

- **client**

    Any directory named `client` is not loaded on the server. Similar to
    wrapping your code in `if (Meteor.isClient) { ... }`. All files loaded on
    the client are automatically concatenated and minified when in production
    mode. In development mode, JavaScript and CSS files are not minified, to
    make debugging easier.  (CSS files are still combined into a single file
    for consistency between production and development, because changing the
    CSS file's URL affects how URLs in it are processed.)


    HTML files in a Meteor application are treated quite a bit differently
    from a server-side framework.  Meteor scans all the HTML files in your
    directory for three top-level elements: `<head>`, `<body>`, and
    `<template>`.  The head and body sections are separately concatenated
    into a single head and body, which are transmitted to the client on
    initial page load.

- **server**

    Any directory named `server` is not loaded on the client. Similar to
    wrapping your code in `if (Meteor.isServer) { ... }`, except the client
    never even receives the code. Any sensitive code that you don't want served
    to the client, such as code containing passwords or authentication
    mechanisms, should be kept in the `server` directory.

    Meteor gathers all your JavaScript files, excluding anything under the
    `client`, `public`, and `private` subdirectories, and loads them into a
    Node.js server instance.  In Meteor, your server code runs in a single
    thread per request, not in the asynchronous callback style typical of Node.
    We find the linear execution model a better fit for the typical server code
    in a Meteor application.

- **public**

    All files inside a top-level directory called `public` are served as-is to
    the client. When referencing these assets, do not include `public/` in the
    URL, write the URL as if they were all in the top level. For example,
    reference `public/bg.png` as `<img src='/bg.png' />`. This is the best place
    for `favicon.ico`, `robots.txt`, and similar files.

- **private**

    All files inside a top-level directory called `private` are only accessible
    from server code and can be loaded via the [`Assets`](#assets) API. This can
    be used for private data files and any files that are in your project
    directory that you don't want to be accessible from the outside.

- **client/compatibility**

    This folder is for compatibility JavaScript libraries that rely on variables
    declared with var at the top level being exported as globals.  Files in this
    directory are executed without being wrapped in a new variable scope.  These
    files are executed before other client-side JavaScript files.

- **tests**

    Any directory named `tests` is not loaded anywhere. Use this for any local
    test code.

- **node_modules**

    For compatibility with node.js tools used alongside Meteor, any directory named
    `node_modules` is not loaded anywhere. node.js packages installed into
    `node_modules` directories will not be available to your Meteor code. Use
    `Npm.depends` in your package `package.js` file for that.

The following directories are also not loaded as part of your app code:

- Files/directories whose names start with a dot, like `.meteor` and `.git`
- `packages/`: Used for local packages, covered below
- `programs`: For legacy reasons
- [`cordova-build-override`](https://github.com/meteor/meteor/wiki/Meteor-Cordova-Phonegap-integration#advanced-build-customization)

### Files outside special directories

All JavaScript files outside special directories are loaded on both the client
and the server.  That's the place for model definitions and other functions.
Meteor provides the variables [`Meteor.isClient`](#meteor_isclient) and
[`Meteor.isServer`](#meteor_isserver) so that your code can alter its behavior
depending on whether it's running on the client or the server.

CSS and HTML files outside special directories are loaded on the client only,
and cannot be used from server code.

### Example File Structure

The file structure of your Meteor app is very flexible. Here is an example layout that takes advantage of some of the special folders mentioned above.
{'fraction_non_alphanumeric': 0.0666578756510846, 'fraction_numerical': 0.0007911914023867607, 'mean_word_length': 4.0814070351758795, 'pattern_counts': {'":': 0, '<': 33, '<?xml version=': 0, '>': 51, 'https://': 5, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2628305', 'n_tokens_mistral': 3981, 'n_tokens_neox': 3779, 'n_words': 2127}