timrwood / moment-es6 Goto Github PK

hook object used for moment -- won't it be better to just define the
moment constructor in the main file to use createLocal, instead of
making abstraction, setting callbacks just to call a function

via @ichernev

global locale -- I think it should be a moment property. I know that
theoretically speaking the more private stuff the better. But to ease
debugging and extensibility -- the more stuff is accessible (and
changeable) the better. I had an idea to put all "private" utils
methods prefixed with underscore under moment, so they could be used
(for hard core cases), changed etc. That is not desirable for
libraries, but for end users who want to get the job done its perfect.

via @ichernev

the way units is organized is good, but I think it would be better
if the mapping is stored under moment, so it can be used by meta tools
:) Also this would allow us (later) to introduce packs (calendars),
register / list / unregister calendars and other plugins adding
tokens, getters and setters. This is similar to the global locale
being made accessible through moment.

via @ichernev

most files have one export at the top, but there are some with
inline exports. I guess we should enforce one export at the top with
jscs or similar.

via @ichernev

I don't like the way you attach stuff to the moment and duration
prototypes. Wouldn't it be better if the separate files just define
one or more related functions, and then the central file just attaches
all functions with a factory or directly. That way you have a quick
glimpse at the entire API, in one file. Also I think the dependency
graph would be much simpler. Individual function files would be
simpler and won't depend on anything except utilities.

Via @ichernev

Right now, we are using nodeunit to run tests in node + browsers.

In order to run tests, nodeunit will run any method on module.exports as a test.

exports.someTestName = function (test) {}

With the es6 module transpiler, we could define tests like so.

export function someTestName (test) {}

Nodeunit runs through every cjs module in a directory and runs the tests on its exports. This works pretty well, but I'm not sure how we will be able to iterate over all these files once they are transpiled in order to run them in the browser.

I'm wondering if we would need to switch to another test framework that isn't so node specific. QUnit perhaps?

Then, test files would look something more like so.

import { module, test, ok, equal } from "qunit";
import { moment } from "moment";

module("create");

test("from array", function () {});

Ideally, the lib + tests could be build into one file via broccoli and run in a browser and node without these browser*.js files.

• Decide on test framework
• Write build process for converting lib+tests to es5 for running tests
• Convert tests to es6
• Write some test helpers for duplicated tests like all the lang specific tests

Thoughts @trek?

the create folder dependency graph is complicated. Maybe because the
logic is complicated too. Can we export everything meaningful from
index.js or similar (that might apply for other folders). That way
when browsing the code there is again a good API listing somewhere

via @ichernev

In order to minimize chaos, it would be nice to have separate repos for source files and distribution files.

Unfortunately, because so many package managers use git urls as their sources, I don't think we can host distribution files on another repo like component/moment.

I think the best plan would be to create something like a moment/moment-source repo that all development is done on, and the only commits on the moment/moment repo would be compiled builds.

Anything specific to distribution would live in moment/moment, and anything related to development would be in moment/moment-source.

# moment/moment
min, .npmignore, .spmignore, changelog, contributing,
license, readme, bower.json, component.json,
composer.json, ender.js, package.js, package.json

# moment/moment-source
benchmarks, locales, lib, tasks, test, .travis.yml,
contributing.md, readme.md, gruntfile.js, brocfile.js, package.json

For the compiled builds, we will probably want to target es6, globals, amd, commonjs, and umd. The file tree might look something like this.

amd/
    locales/*
    moment.js
commonjs/
    locales/*
    moment.js
es6/
    locales/*
    moment.js
globals/
    locales/*
    moment.js
umd/
    locales/*
    moment.js
component.json
composer.json
bower.json
package.json

For all these environments we will probably need to decide whether to bundle the source into a single file or not.

We will also need to figure out if we want to have a version with the locales bundled, a version without the locales bundled, or both.

We should also consider if we want to provide a minified copy of each version.