Now that CLI sends User Agent containing node and cli version, we should

• Deny publishing for old versions asking the user to update
• Deny publishing for old versions of node.js asking the user to update

let the flame wars, begin!

Rather than just returning a static value, it would be nice to have the option to run a function.

A-la hapi's server.dependency(...).

It succeeds, but S3 is kind of messed up

this.

There is a bug when publishing to 2 registries: the first publish succeeds, then the package.tar.gz is removed, then the second publish fails

Thanks @ajcw for reporting this.

When accessing the registry main url with a Content-Type: text/html would be cool to

• list the component in HTML format
• provide component information and api using the /{component}/{version}/~info route
• ideally, provide a simple sandbox to allow hacking on the component and seeing an html preview using client-side rendering

When using the preview feature there is no feedback if an error occurs. It would be nice to spit out the error messages, even if just to console

This works perfectly.

var configuration = {
...
  publishAuth: {
    type: 'active-directory',
    options: {
      url: 'ldap://dc.domain.com',
      baseDN: 'dc=domain,dc=com'
    }
  }
};

var registry = new oc.Registry(configuration);

• When publishing, user should be prompted to insert email and password in the CLI. Email should then be remembered and saved inside compiled package.json - so that we know who published what.
• Authentication should happen on the server, so as soon as the user is asked to prompt username and password, they should be sent to the registry together with the publish request. That said, it would be a good idea to force the user to use HTTPS endpoints (at least) when doing the publish operation.
• We need to figure out if and how this would fit for the grunt plugin.

@andyroyle it would be good to have your opinion about this

This is needed in order to get japanese properly previewed

We are having many errors during test execution with travis+saucelabs.
Usually, reds that last more than a couple of minutes are visible here: https://travis-ci.org/opentable/oc/builds

According to support, we may want to change karma configuration to set browserNoActivity to 120s.

In addition, we may want to try hacking on the browserDisconnectTolerance parameter.

In following situation error is swallowed be oc dev repository - it would be nice if oc displayed information in some way other than component data resolving error:

module.exports.data = function(req, callback){
  var request = require('request');
  request({
    url: 'some-url',
    json: true
  },
  function(err, res, body){
    if(err || !body){
      return callback(err);
    }

    ...

    callback(null, {
      someValue: 'value'
    });
  });
};

Since the components are (currently) executed inside the same process as the registry, a poorly (or maliciously) written component that contains an infinite loop can bring the registry to it's knees (i.e. cause the execution to get stuck inside a never-ending thread).

We could use something like burrito to walk the server.js code for a component (either at publish time or execution time) to inject code that can dump out and return control in the event that a loop runs for "a long time".

var burrito = require('burrito');

var serverjs = "module.exports.data=function(){ var x=0; while(true){ x = 123; } for(var i = 0; i < 1e10; i++) { console.log('blarg'); } callback(null, {}); };";

var CONST_MAX_ITERATIONS = 1e7;
var monitoredKeywords = ['while', 'for', 'do'];

var src = burrito(serverjs, function (node) {
  if(monitoredKeywords.indexOf(node.name) > -1){
    node.wrap('{ var __ITER = ' + CONST_MAX_ITERATIONS + ';  %s }');
  }

  if(node.parent() && monitoredKeywords.indexOf(node.parent().name) > -1 && node.name === 'block'){
    node.wrap('{ if(__ITER <=0){ throw new Error("loop exceeded maximum allowed iterations"); }  %s __ITER--; }');
  }
});

This would wrap the loops in a block and give them an iterator and a check:

module.exports.data = function() {
    var x = 0;
    {
        var __ITER = 1e7;
        while (true) {
            if (__ITER <= 0) {
                throw new Error("loop exceeded maximum allowed iterations");
            }
            {
                x = 123;
            }
            __ITER--;
        }
    }
    {
        var __ITER = 1e7;
        for (var i = 0; i < 1e10; i++) {
            if (__ITER <= 0) {
                throw new Error("loop exceeded maximum allowed iterations");
            }
            {
                console.log("blarg");
            }
            __ITER--;
        }
    }
    callback(null, {});
};

Why?
Components without containers can have js and css designed to work when placed in a specific position of the DOM tree. This is not probably good design for componentising front-end, but this is a good investment anyway. Actual behaviour, when doing client-side failover or just client-side rendering, places content inside <oc-component> container.

Current behaviour:

<oc-component ... data-rendered=true id='xxx'>
  <div>
    This is the component
    <span>Hi!</span>
  </div>
  <div>This is still the component</div>
</oc-component>

Containers are good also because we know exactly what is inside component. We may want to re-render and do something cool with the component and we have a specific scope.

To achieve client-side rendering without a container, we should probably do something like this:

<oc-component ... data-rendered=true data-oc-component-target='yyy'>
</oc-component>
<div data-oc-component-id='yyy'>
  This is the component
  <span>Hi!</span>
</div>
<div data-oc-component-id='yyy'>This is still the component</div>

So even with external rendering,<oc-component> is present in the page, but is linked to all of the components' parts injected after it. In this way, we have all we need to do re-rendering, nesting, etc.

NOTE: this is only for when component has container=false in his package.json.

Currently, we use the name pre-rendered as the renderMode for retrieving a raw template and data from a registry. I think this name is confusing - I would generally assume that a "prerendered" template would be the same thing as what we're calling "rendered."

I propose that we change the pre-rendered mode name to something more like unrendered. This is a mostly cosmetic change that I think will aid in comprehension of what's actually being returned by that render mode. More than willing to submit a PR if people feel similarly.

This will constitute a breaking change, so we'll probably want to add a deprecation cycle for this behavior.

Just the component's date, same as we do for the version.

Not possible ATM due to custom tags. Need a IE8 failover strategy such as injecting a conditional IE8 condition to avoid using the custom tag.

Need to allow the cli to init a new component for jade.
Something like

oc init jade-component <templateName>

So, I would just name handlebars the current one (still the default) and jade the new one.

Components' server.js code should be executed by another service, so that the registry have the single responsibility of binding the library and the runtimes to the consumers

This will improve robustness and scalability.

In order to make it dependency-free(ish?) and thin

• Optionally on registry configuration
• Cli has to try publish first then ask for login in case registry asks for password
• Cli should not save anything on local computer

• Optional
• Has to be shown on web interface

If the component has even a single space, it is fine.
If multiple components are there, the component shows "Loading..." and prevents other components to be rendered. Gently reported by @ajcw

We need to understand what kind of issues we may have with different IE versions. Specifically,

• CORS integration for old browser
• support for custom tags
• ?

For each one, then, we have to think about what options we have to solve it.

The cli often claims the component is not valid - would either need better error details or fix it.

So that the registry has a recent version of the client to serve

Instead, it stops and has to be restarted manually. Bring to the client some debugging info would be cool too.

It would be cool for the client-side client to be able to:

• Optionally set a maximum number of retries
• Optionally set a parameter to report the retry number (http://server/component/...?__oc_Retry=2)

As it is synchronous stuff, instead of doing this:

var registry = new oc.Registry(configuration);

if(registry.err){
  return console.log(registry.err);
}

e.g. oc ls --registry=http://my.regsitry.com

via transpiling when packaging

https://github.com/facebook/regenerator
https://github.com/6to5/6to5

So that it is possible to handle logging and customisations.

as the one currently used (https://github.com/harthur/nomnom):

• is not maintained: https://github.com/harthur/nomnom#deprecation-notice
• has a lot of bugs

I can work on it - any recommendations for parser?
https://github.com/tj/commander.js?

We should start writing the docs.

• Getting started (component init, dev) with examples
• Registry advanced configurations
• server.js advanced development and api
• node.js library - usage and api
• client-side library - usage and api
• cli - commands

Using the package.json's property:

{
...
"oc": {
    ...
    "minify": true
  }
}

this is just for publishing, and defaults to true.

• We need to investigate what currently happens when using jade includes
• In case we want to be opinionated about not supporting it, we need a clear message error
• In case we want to be opinionated about supporting it, we need to make it work smoothly

I think supporting it is possible, but we need a better investigation first.

Short term I would say that we should ensure proper file type is set for:

• png
• jpg
• css
• js

So that we ensure tests are green on all platforms

Scenario:

When multiple registries are connected to the same library
And I publish a component to one of the registry
Then all the registries should re-cache the components list
And all the registries should re-cache the component's versions list

We need to setup some tests in order to start cleaning up oc-client, perhaps setting up karma and jasmine.

• connect sauce-labs for executing tests via karma
• test coverage for the oc-client

When packaging happens, we should write inside the package.json the oc version for future reference.

Packaging happens in 2 situations: when cli dev (running a local dev registry) and when doing cli publish (just before contacting a registry).

The package.json is written inside the _package folder and should contain the oc version (we can retrieve it on the package.json on the oc root).

would be good if when doing oc preview http://.../component?param=1&param2=hello the window could open http://localhost:xxx/?param=1&param2=hello having the possibility to change the url in order to test different params values.

Including the CLI Version. So, when introducing breaking changes in the Registry, we can ask the user to upgrade the CLI.

It should be possible to run any cli command as grunt task as well, with the possibility of explicitly declaring all the parameters.

• Refactor cli facades in order to standardise input and output (return all the callbacks)
• Use the same facades to create a set of grunt tasks and expose them. Something like:

var oc = require('oc'),
      OcGrunt = new oc.Grunt();

Currently oc parses all node_modeules files which is sometimes causing problems (nock) - it should only parse dependencies specified in package.json