zerotohero-dev/babil

[UNMAINTAINED] Babil transpiles all your dependencies without needing grunt or gulp.

babil's Issues

add inline documentation.

use jsdoc or something similar.

check for required babel modules to exists too

the project shall have the modules that are specified in babel configuration json; otherwise the transpilation won’t be done.

so if the module does not exist, install it and modify the package json and let the user know about it.

src is redundant in the release folder.

When the transpilation is done the folder structure is like ./release/src/foo/bar it should be ./release/foo/bar instead.

move files one level up.

utilize default parameters

instead of this

babil.initialize( {
    srcPath: join( __dirname, 'lib' ),
    rootPath: join( __dirname, '..',
    babelPath: join( __dirname, '../node_modules/babel-cli/bin/babel.js' )
} );

do this

babil.initialize( { cwd: __dirname } );

and let the rest of the options get defaults from that parameters.

make sanity check before running the program

• check if the babel executable can be found
• check if you can create the release folder
• check if you can create a file in the release folder
• warn the user if any sanity check fails, and prompt her for possible corrective actions.

make babil backwards compatible

it should transpile itself to make it work in all the places.

I’m not sure if it’s a duplicate issue.

use a proper error object.

    if (!rootPath) {
        throw 'Please provide a root path.';
    }

instead of throwing a string, use a descendant of the Error object (something like VError)

Check for outdated modules.

Before every build the pipeline should check for outdated modules.

What happens:

Currently a dependency can go out-of-date without raising any alarms.

Expectation:

Out of date modules should either raise a warning or break a build.

transpile babil to older versions and selectively use transpiled files for older node runtimes

babil requires node v.6 or above.

that’s not a big deal for demo use and to be used in screencasts etc;

however, it should also transpile itself so that unsupported runtimes can use it from the release folder.

Integrate eslint

EcmaScript of the project should be checked using eslint.

what happens:

Currently there is no syntax checking.

expectation:

project should be statically validated before publishing.

create a cli

simplify `walker.on('directory``

the promise is redundant;

let mkdir call next instead.

update readme; add more examples

and also add a link to the examples folder.

use a proper logger.

enable automation

each merge to master should trigger a new build.

test single directory without subfolders case.

if the src folder has only files and no subfolders, the release folder should be created anyway.

What happens:

Given ./src/foo.js no file is processed.

Expectation:

It should have created a release folder and ./release/foo.js and ./release/foo.js.map

add tests and coverage reports.

Use a framework like mocha to add unit tests.

Having coverage reports will also be nice.

I won’t pick a coverage percentage.

You should try and not focus on the coverage percentage per se, or try to find an arbitrary number for it, but instead focus on having as much logic and functionality tested as is humanly possible.

It is quite reasonable to have a, say, 50% coverage rate if only because only 50% of the code contains logic that can be tested, and the other 50% happens to be simple DTOs or things that are handled by a framework (where you don't need to test the functionalities of your framework) for instance.

Also

If you make a certain level of coverage a target, people will try to attain it. The trouble is that high coverage numbers are too easy to reach with low quality testing. At the most absurd level you have AssertionFreeTesting. But even without that you get lots of tests looking for things that rarely go wrong distracting you from testing the things that really matter.

Like most aspects of programming, testing requires thoughtfulness. TDD is a very useful, but certainly not sufficient, tool to help you get good tests. If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

The reason, of course, why people focus on coverage numbers is because they want to know if they are testing enough. Certainly low coverage numbers, say below half, are a sign of trouble. But high numbers don't necessarily mean much, and lead to ignorance-promoting dashboards.

~via: http://martinfowler.com/bliki/TestCoverage.html

Also see: http://www.artima.com/weblogs/viewpost.jsp?thread=203994

add babel-cli and es2015 as dependencies

This will help them be installed if parent project does not have them.

If the app cannot find either of them; then ask if it os okay to install and use them right now.

Why do we need babil, when babel can do the same?

Not sure if I was drunk or something when creating this library… but…

"babel lib --source-maps -d release" inside npm scripts, almost does the same thing in a much leaner way.

One advantage of babil is: it comes bundled with certain required dependencies, and does some preflight checks.

Though is it worth the hassle?

I don’t know.

remove 'use strict's

es6 modules are "strict" by default; no need to use use strict in NodeLandia.

create default .babelrc if it does not exist.

echo '{ "presets": ["es2015"] }' > .babelrc

Extra `release` folder gets created for some reason

This code

const babil = require( 'babil' );
const transpile = babil.transpile;
const join = require( 'path' ).join;

const ROOT_PATH = join( __dirname, '..' );

babil.initialize( {
    rootPath: ROOT_PATH,
    srcPath: join( ROOT_PATH, 'generators/app/lib' ),
    releasePath: join( ROOT_PATH, 'generators/app/release' )
} )
.then( transpile );

creates a release folder at the project root; it should not.