build: add Bazel build system

[CaerusKaru]

This is a continuation of #4, which got a little messed up when the repo was made public.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[CaerusKaru]

Apologies to anyone tracking for the commit spam. Here's the current status:

• All build steps pass locally and on CI. This includes all packaging and release steps through jsii-release
• All tests currently build and run correctly. The only errors are due to out-of-date snapshots. Functionality to update the snapshots through Bazel is pending
• All examples build and generate the imports files through Bazel correctly, in addition to tests. However example synthesis is still pending (though is mostly done). Though strictly speaking they synthesize correctly, they don't end up in the correct directory for easy use

tl;dr only two things left: snapshot test updation through Bazel, example synthesis through Bazel

[CaerusKaru]

Progress update:

• Jest tests all pass and snapshot updation is covered and working. The CLI tests need an NPM patch so that require.resolve will work correctly with JSII
• Example synthesis is still pending, but is the only major hurdle left

[eladb]

Haven't finished reviewing everything, but here is an initial round of comments.

[eladb]

What are these doing?

[CaerusKaru]

In order for Bazel to get setup correctly, we need to move the CI bazelrc file into place (/etc/bazel.bazelrc) and then we need to initialize Bazel with the CI's PATH variables (any any other ENV we need at build time). I can add comments to this file if you think it will help.

[eladb]

Why do we need two commands here?

[CaerusKaru]

The first one moves the top-level Bazel RC file into place, only on CI. The second is a command used by all consumers of the library. We could fold it into prebuild (I have a comment on that in the package.json right now), but both commands are required. We could rename them too to make it clearer.

[CaerusKaru]

Progress update:

• CLI tests are working fine now. Snapshot updation has a minor issue in the examples, but tests run regardless Snapshot updation is fully working in all cases.
• Examples synth is still pending
• Fixed a packaging issue that preventing yaml from getting bundled with the library. Also added the LICENSE file

[CaerusKaru]

All systems go! There is one precondition for doing example synthesis that I'm trying to make easier, but in the meantime the base functionality for the entire repo has been replicated with Bazel in some form.

[eladb]

@CaerusKaru can you do one last merge from master and I'll pick this up

[CaerusKaru]

@eladb Should be all set 👍

[eladb]

I am getting the following message when running "yarn install":

Unrecognized patch file in patches directory rules_nodejs.patch

[eladb]

I expected constructs to also appear in devDeps here. I actually want to make sure the devDep is pinned on 2.0.0 because that's the lowest version we currently support.

[CaerusKaru]

devDeps are not needed for package publishing, otherwise package version is handled solely at the root package.json level.

[eladb]

Is this name really needed? This produces a package.json file, can we have a default on the name?

[CaerusKaru]

We can have a macro that defaults the name, sure. But the name corresponds to the target and is a mandatory parameter for Bazel actions.

[eladb]

seems inconsistent. In some places this is called module_name and here package_name. Can we normalize?

[CaerusKaru]

module_name is a ts_library parameter that we inherit (this allows us to use jsii_library as a dep for ts_library targets). package_name can be converted to module_name for consistency, but I thought package_name was clearer here.

[eladb]

Can probably be omitted if we have a default name for the package_json rule, no?

[CaerusKaru]

Only if we also adapt the jsii_library to be a macro that accepts the default. In my mind, we'd have one jsii macro that sets up the package_json, jsii_library and jsii_package targets all in one. This has the benefit of being DRY but also allowing the user to trigger the individual actions.

[eladb]

Feels like a duplicate from package.json, can we remove?

[CaerusKaru]

Only if we incorporate the deps aspect into the package_json rule, but sure.

[eladb]

why isn't this @npm//constructs or something like that?

[CaerusKaru]

This is translated raw to the package.json. It doesn't incorporate the actual package as a dep (though it could if we decide that's the way to go).

[eladb]

I expected these to reference the @npm// scope somehow instead of hard code the versions here, no?

[CaerusKaru]

That could be incorporated into the package.json rule, sure.

[eladb]

What's the difference between jsii_library and jsii_package? Why do we need both?

[CaerusKaru]

jsii_library -> jsii
jsii_package -> jsii-pacmak

Each requires separate tooling, and so should remain separate (when you develop a project, you don't invoke jsii-pacmak every time)

[eladb]

I am wondering if we even need package_json here. Seems like we can probably merge it (and jsii_package) into jsii_library which will just do everything. I don't see any reason to split those up really.

Basically, I'd expect this file to look something like this:

jsii_library(
    name = "lib",
    desc = "Cloud Development Kit for Kubernetes",
    stability = "experimental",
    jsii_targets = JSII_TARGETS,
    srcs = glob(
        [ "**/*.ts", "README.md" ],
        exclude = ["test/**"],
    ),
    module_name = "cdk8s",
    dev_deps = [
        "@npm//@types/json-stable-stringify",
        "@npm//@types/node",
        "@npm//@types/yaml",
        "@npm//constructs", # this needs to be pinned to 2.0.0
    ],
    peer_deps = [
        "@npm//constructs",  # this needs to be ^2.0.0 (not sure how to express)
    ],
    bundled_deps = [
        "json-stable-stringify",
        "yaml"
    ]
)

Something along those lines.

[CaerusKaru]

I think it's important to have separate, same with jsii_package, because it's a separate action. We can create a macro to encapsulate the behavior you're talking about, but leaving these compose-able gives us some advantages. E.g. we don't need to recompile a library every time we want to package it. Or we can reuse the package.json elsewhere without compiling the library (important for test path resolution).

[eladb]

@CaerusKaru this is not good enough yet... too much duplicated information all over the place. Repeating that one of the main motivations for me is to "DRY"-up all the info that we need to supply in order to build. I want to be able to provide the minimum amount of information and never repeat myself if not needed.

[CaerusKaru]

@eladb There is more we can do in terms of compartmentalizing by creating macros, but really it's up to you to determine the ergonomics you want. So far my goal has just been to get the project "working" in an MVP state. How you want it to work after that is really just gravy now that it does work.

[eladb]

Yes I understand. Let me try to play with this a little to see if I can get to the ergonomics I want

[eladb]

@CaerusKaru I think I am going to close this one for the time being. I don't think I have the time in the next few months to spend on getting this to a place that I would feel comfortable merging. @iliapolo would you be interested to look into this perhaps?

[eladb]

@CaerusKaru I really appreciate all the effort!

[iliapolo]

@eladb definitely. I’ll see if I can pick this up.