miguelcastillo / bit-loader Goto Github PK

Maybe task because transforms are not limited to just source transformation even though that their primary use case.

It would be even better if the transformation pipeline became its own small project that's just for running tasks.

Currently, plugin authors depend on the dependency stage to execute anything that has to happen after all the transforms have executed. But using the dependency isn't as semantically correct for generating exports. So to make the plugin language a bit more accurate, adding a precompile stage will help. This stage is async and will run in the loading phase.

Currently, the .travis.yml sets the node version to 0.11. I think we should use the latest stable release, and as such, go for 0.10 instead.

Other changes include:

1. Adding a proper resolver step
2. Adding a plugin system to register functionality into the different pipelines
3. Fetch is no longer responsible for creating meta object. It is now done by bit-loader before resolving module names.

The idea is to enable access to the compilation step in order to support importer.register for modules that need to be compiled.

The issue with this is that if we allow plugins to process other plugins when they dynamically loaded, we are going to get deadlocks.

For example, the following sequence of plugins will cause a deadlock because the first plugin will depend on the second one to load, and the second one depends on the first to load.

P1 -> P2.

Deadlock: P1 triggers P2 to load so that P1 can be processed by P2. When P1 is loading P2, P2 then needs to load P1 so that P2 can be processed by P1. This is a deadlock...

So, we should only do forward processing. Meaning, P1 can load P2 so that P2 can process P1, but P2 cannot load P1 so that P1 can process P2. This approach is a bit fragile because users will need to be aware of this. Ultimately, we completely block plugins from processing other plugins by automatically adding dynamic plugins to the ignore list.

Add a way to define a transformation where other transformation execute in a particular order before the transformation itself is executed.

Similar to gulp tasks:

gulp.task('x', ['a', 'b'], function() {
  // do something
});

Here we have a task called x that before it is executed, a and b are executed. Only then will the callback get called. The callback is optional so that a simple chain of transforms can just be executed.

Since npm does not need tests or the source, we can ignore those when publishing to npm using npmignore.

Currently the way that register works is a bit weird. It accepts a factory method to initialize the module instead of just setting the exports.

Use Utils.printError

adding dynamic plugins to the ignore list will prevent plugins form processing other plugins. We want to block this so that plugin author and users of plugins don't have to worry about the intricacies steaming from plugin deadlocks as described here #127

If plugins are just not processed, then plugin author simply gotta make sure they pre process and bundle their stuff up, and that's what bit loader will use.

This is to enable putting meta modules through the transformation pipeline without forcing the module source to be fetched first.

Use case - Enable a site that shows input and output from the transformation process

/cc @Mark-Simulacrum

This is so that relative and absolute module paths point to the same module

This is to enable pushing instance creation as far back as possible so that we can use System.register to register modules that can be compiled and consumed with System.import

moduleParent is supposed to be a Module.Meta object, but its a mutable it's not reliable. So, switching to using a referer to provide a way to specify the parent module path is more specific and less ambiguous.

Currently, module meta objects are VERY lose objects and get verified when they get put through the loader pipeline, which is really late. Creating a factory will move any format inconsistencies to immediate failures rather than delayed failures.

A blacklist of transforms will allows to configure, based on some acceptance criteria, whether or not a transform should run against a particular module meta. This way we can specify things like transforms that are specific to css/less/js/coffeescript...

This relates to #16, where creating transformation dependencies can be used to leverage to define transformations that need to be executed. And the other part is leveraging plugins in a module meta object to define what tasks run against them.

for example,

loader.transform.use("test", ["a", "b"]);

loader.import("test!something", function(something) {
   console.log('executed transform "test", which basically is running "a" and "b"');
});

When module something is loaded, the transformation test is executed on it.

Promise implementation should be polyfilled by the host application

This will make it much simpler to enable dependency injection.