lunchclass/bacardi

Bacardi project is an effort to provide multi-language binding for Node.js native layer.

Bacardi

Bacardi project is an effort to provide multi-language binding for Node.js native layer.

System requirements

• This project is multi-platform oriented, so we support Linux, Mac and Windows platforms.

Linux

• You MUST have git, python, wget and g++ compilers.
  • sudo apt-get install g++ git make python wget

Mac

• You MUST have Xcode with command line tools. You can install them as follows:
  • xcode-select --install

Windows

• You MUST have git. Others will be installed automatically when bacardi command is executed.
  • Visit to https://git-for-windows.github.io in order to install git.

Build

• You can just run the following command to build.
  • ./bacardi build

Test

• You can just run the following command to test.
  • ./bacardi test

Electron with Bacardi

• If you want to run Electron with Bacardi, you can run the following commands.
  • ./bacardi build_electron
  • ./bacardi electron

Coding style

• We are following Chromium coding style. You can see the details in the following link.
  • Chromium C++ style guide
• If you want, you can just run the following command to format source codes you modified automatically.
  • ./bacardi format

bacardi's Issues

Add byte and octet types

need to support byte and octet basic types

Byte - the byte type is a signed integer type that has values in the range [-128, 127].
Octet - the octet type is an unsigned integer type that has values in the range [0, 255].

Split binding.gyp into smaller .gypi files.

We need a modulization for binding.gyp.
Reference: https://gyp.gsrc.io/index.md

Windows build support.

We should add support for windows build.

Auto execute format and test If needed

Our test command now exits with a "You should run |bacardi format| command first." message if format is required.

This means that the user must explicitly type the bacardi format and type the bacardi test again, which is very annoying.

And some test case failed in AppVeyor if need format.
please refer to link
https://ci.appveyor.com/project/romandev/bacardi/build/1.0.257/job/e32eve5hgrivpnkj

So I would like to suggest is that if we need bacardi format when you type bacardi test, we execute format and test automatically?

As a result, user cannot see "You should run |bacardi format| command first" message and user can test by typing bacardi test only.

Move bacardi.cc path to core.gypi?

present bacardi.cc file is auto generated.
actually it is related with idl files. so bacardi.cc path was wrote in example.gypi for gyp build.
(https://github.com/lunchclass/bacardi/blob/master/examples/examples.gypi#L29)

it means bacardi user have to write bacardi.cc file path in their's gypi files.
is it fine? or should we move to that files to core.gypi?
i think it is better to hide auto-genreated files to user.

cc @romandev , @yjaeseok, @daehyunjimmy

Remove template/example.njk file.

The file is no longer necessary.

Use jest instead of Mocha

Reason: The readability is better I think. WDYT?

/cc @yjaeseok @hwanseung

Write a contribution guide for external contributors.

At least, we need the following things:

• Setup environment for development.
• Download codes
• Upload patch
• Send PR request with review.
• AUTHORS file.
• Coding style guide
• Tools

[Meta] RoadMap for feature implementation.

Interface Members

Feature Name	Priority	Status	Owner	Issues or PRs
Constants	P3
Attributes	P1	Done	@byeolbit
Operations	P1	Done	@romandev
Stringifiers	P2
Indexed properties	P3
Named properties	P3
Static attributes and operations	P1	Done	@romandev, @byeolbit
Overloading	P1	In Progress	@yjaeseok, @romandev
Iterable declarations	P3
Maplike declarations	P3
Setlike declarations	P3

Basic Types

Feature Name	Priority	Status	Owner	Issues or PRs
any	P1	In Progress	@daehyunjimmy	#163
boolean	P1	Done	@gogag2
byte	P2	Done	@daehyunjimmy
octet	P2	Done	@daehyunjimmy
short	P2	Done	@gogag2
unsigned short	P2	Done	@nadongguri	#156
long	P1	Done	@gogag2
unsigned long	P1	In Progress	@usefulhyun	#158
long long	P2	Done	@corona10
unsigned long long	P2	In Progress	@usefulhyun	#158
float	P1	Done	@gogag2
unrestricted float	P1
double	P1	Done	@gogag2
unrestricted double	P1
string	P1	Done	@romandev
object	P1
symbol	P3
Interface types	P1
Dictionary types	P1
Enumerations types	P1	In Progress	@hwanseung
Callback function types	P3
Nullable types	P1
Sequence types	P1
Record types	P3
Promise types	P1
Union types	P2
Annotated types	P3
Buffer source types	P2
Frozen array types	P2

Special things

Feature Name	Priority	Status	Owner	Issues or PRs
Namespaces	P3
Dictionaries	P1	In Progress	@hwanseung
Enumerations	P1	In Progress	@hwanseung
Callback functions	P3
Typedefs	P1

Extended attributes

Add support for Electron example

It can be useful for developers.

Introduce TypeScript for developer performance.

The TypeScript is a language for application-scale JavaScript. It provides many things for developer convenience such as TypeSystem and access modifiers and so on. So, we can consider to introduce TypeScript for developer performance and convenience.

Need a test framework for C++ codes.

We already write some C++ codes but there are no tests for them.
(Currently, only have JS side tests using Mocha.)
So, we should introduce a test framework (e.g. gtest) for C++ codes.

Refactor codes main.ts and idls.ts.

The complexity of the two files has increased, on the other hand, readability has decreased. We should split into smaller files and clear their purpose.

Add support basic type conversion.

Currently, we are only supporting |double| type in calculator examples.
But we should support for basic type such as integer, boolean and so on.

Need more example

I think it would be good to think of an example that better explains the effect of bacardi project.
We have only calculator.

Should implement JSTypeTraits.

We should implement JSTypeTraits similar to NativeTypeTraits.
It should provide converted JS value from Native value.
For example, if the Native value is a double type, should return Napi::Number.

Should implement method overloading feature.

We should implement method overloading feature.
https://heycam.github.io/webidl/#idl-overloading

Can not use IDL long type as return type.

In the current implementation, we can not use IDL long type as return type. If we add some test method returning long type, the following build error occurs.

.././core/js_type_traits.h:25:10: error: no viable conversion from returned value of type 'long' to function return type 'Napi::Value'
  return T();
         ^~~
Release/obj/gen/test/test_interface_bridge.cc:286:10: note: in instantiation of function template specialization 'JSTypeTraits<long>' requested here
  return JSTypeTraits(info.Env(), return_value);
         ^
/Users/zino/bacardi/node_modules/node-addon-api/napi.h:118:9: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'long' to 'const Napi::Value &' for 1st argument
  class Value {
        ^
/Users/zino/bacardi/node_modules/node-addon-api/napi.h:118:9: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'long' to 'Napi::Value &&' for 1st argument
1 error generated.

The above error is because there is no template-specialization for long type in JSTypeTraits.
So, if we add the specialization, it works. But it's not a right way I think.
The long type's range might be changed in C++ side depending on each platform. So, we should find a better way to map explicit range type such as int32_t.

Replace "Lunch Class Authors" with "Bacardi Authors" in boilerplates.

We should replace "Lunch Class Authors" with "Bacardi Authors" in boilerplates of each files.

Before Copyright (c) 2017 The Lunch Class Authors.

After Copyright (c) 2017 The Bacardi Authors.

Should implement |attributes| feature in Interface.

We should implement |attributes| feature in WebIDL interface.
https://heycam.github.io/webidl/#idl-attributes

I got some warning message, in first build

When I first got the bacardi source download from github and tried it, the following warning occurred.
This warning is likely to be removed.

/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h: In instantiation of ‘static Napi::ClassPropertyDescriptor Napi::ObjectWrap::InstanceMethod(const char*, Napi::ObjectWrap::InstanceMethodCallback, napi_property_attributes, void*) [with T = CalculatorBridge; Napi::ObjectWrap::InstanceMethodCallback = Napi::Value (CalculatorBridge::*)(const Napi::CallbackInfo&)]’:
../examples/calculator_bridge.cc:25:67: required from here
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::utf8name’ [-Wmissing-field-initializers]
napi_property_descriptor desc = {};
^
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::name’ [-Wmissing-field-initializers]
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::method’ [-Wmissing-field-initializers]
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::getter’ [-Wmissing-field-initializers]
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::setter’ [-Wmissing-field-initializers]
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::value’ [-Wmissing-field-initializers]
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::attributes’ [-Wmissing-field-initializers]
/home/jake_ubuntu/Workspace/lunchclass/bacardi/node_modules/node-addon-api/napi-inl.h:2419:36: warning: missing initializer for member ‘napi_property_descriptor::data’ [-Wmissing-field-initializers]

Should add support for static function.

Currently, we are supporting instance method but not support static function.
So, we should support it as follows:

interface Test {
    static double hello();
};

Then, we can use it as follows:

bacardi.Test.hello();  // Call the static function without instantiation.

Should implement NativeTypeTraits.

We need a way to convert JS value to Native value easier.

Add unit test case for c++ (eg. NativeTypeTraits)

We need unit test case for c++ classes

Update nodejs from v8.2.1 to v8.4.0

We are using napi_create_number() to get double value from C++ code.
But the function was deleted on v8.4.0 and it also didn't work well.
So we need to change it as napi_create_double() that is new api for getting double value.

Move TypeScript build to gulp.

We are using gyp build but it's very 쓰레기. So, I'd like to move TypeScript build to gulp.

Migrate the calculator example to C++ code.

The calculator example is written in C++ language but it's also using built-in N-API based on C language.
We introduced node-addon-api in #36, so, we can just replace it with C++ wrapper code fully.

Need more test set for CalculatorExample: Sub()

We need more test set like Sub.
And we should think modularization about common code.

Add some badges in README.md

We have already two badges. Travis and AppVeyor. But we still need some additional badges such as Slack link and License link.

So, you can just update the following links in README.md:

https://img.shields.io/badge/License-Apache%202.0-yellowgreen.svg
https://img.shields.io/badge/slack-online-green.svg

Need to change fixed code to generated by template

in interface_header.njk & interface_cpp.njk, fixed code need to be generated by template.

Bridge files should be generated by code generator.

In the current implementation, calculator_bridge.h, calculator_bridge.cc files have been written by our authors. But they should be generated by code generator from now. So, we should implement code generator to fit the example.

Split example test into feature unit tests.

To implement POC ASAP, we didn't consider project structure much, especially, testing part. As the number of contributors grows, we need to write more tests and make the structure robust.

CalculatorExample: Add() should take arguments and process them.

In the current implementation, Add() method takes arguments in C++ level but exposed JS layer doesn't take arguments and process them. So, we are just passing hard-coded value and it always returns the same value (3).

bacardi/examples/calculator_bridge.cc

Line 28 in 113a0bb

napi_status status = napi_create_number(env, Calculator::Add(1, 2), &sum);

We should make the function process the arguments and convert types between JS level and C++ level.

Introduce Travis bot for Linux build test.

Once the #1 issue is resolved, then we should introduce Travis bot for build test.

Auto generate JSTypeTraits

We need to generate core/js_type_traits.h automatically.

Need a NPM Packaging.

We need a NPM packaging for Bacardi for third-party use.

Attributes need getter and setter

In user implementation code, attributes need getter and setter.

e.g.

// Attribute
double double_number;

// Getter and setter for attribute
double GetDoubleNumber();
void SetDoubleNumber(double number);

Implement a simple code generator.

We should implement a simple code generator.
It should take IDL files as an input and print C++ classes that maps with IDL files on the screen.

The bacardi.cc should be generated by code generator.

The bacardi.cc and bacardi.h files are in examples directory currently. The file is used to initialize bridge classes but we are not sure what is added newly in the future. Therefore, we should make it be generated automatically.

We can not use camelCase method name.

In the current implementation, we can not use camelCase naming.
For example, if the camelCase() method is defined in interface as follows:

interface ExampleInterface {
    void camelCase();
};

Our generator generates codes as follows:

class ExampleInterface {
    void Camelcase();    // This is a bug.
};

Setup build environment for Linux first.

We should support for native build environment. Currently, first target is Linux platform.

Stop using C based N-API.

We already migrated example codes to C++ based N-API but the core/ directory is still using C based N-API.

support to snake_case filter in nunjucks files.

if interfaces has CamelCase name,
it have to change to snake_case for cpp files name and Include guards.
so we should support to snake_case filter in nunjucks files.
present we don't have interface which name is CamelCase.

Should implement constructor in WebIDL.

In the current implementation, we allow to create object in JS side although there is no constructor definition in WebIDL. It's seems a bug. We should allow to create object with constructor in JS side only if there is an explicit constructor in WebIDL level. To resolve the issue, we should implement constructor feature.

Do we really need to use GYP build system?

Do we really need to use GYP build system?
The Chromium projects (including V8) are already moved to GN build system.
If possible, we can consider GN build system or another thing.

Tests are not working in CI tools.

Tests are not working in CI tools.
after meged #135 CL, tests were passed in CI tools.
because SimRank codes did not formatting like us coding style.
so when run ./bacardi test command, it just show message for formatting and skip the tests.

Should implement enum feature.

We should implement enum feature.
https://heycam.github.io/webidl/#idl-enums

Introduce C++ lint and formatter tool.

We should introduce C++ lint and automatic formatter tool.

idl file can have one more interfaces.

idl file can have one more interfaces. but we didn't generate one more bridge classes.

Multi platform build

Since Bacardi provides multi-language bindings for the Node.js native layer.
Building binding layer for multi-platform is the essential feature.

• Windows -> Linux
• Windows -> MacOS
• Linux -> Windows
• Linux -> MacOS
• MacOS -> Windows
• MacOS -> Linux