docs(adr): setting up adr, start to write 00001-plugin

Author: kwonoj

docs/adr/00000-whats-the-big-idea.md

@@ -0,0 +1 @@
+### This adr attempts to describe 10,000ft view for the swc project itself. To be filled gradually.

docs/adr/00001-support-transformation-plugin-native.md

@@ -0,0 +1,68 @@
+# [Support transform plugin in native rust binaries]
+
+* Status: accepted <!-- optional -->
+* Deciders: @kdy1, @kwonoj <!-- optional -->
+* Date: 2021-01-01 <!-- optional -->
+
+Technical Story: [Issue](https://github.com/swc-project/swc/issues/2635) <!-- optional -->
+
+## Context and Problem Statement
+
+SWC wants to support load, run plugins in the native binary for the custom transform behavior. SWC already have priliminary support to load plugins in its node.js JS bindings but it has known limitations.
+
+## Decision Drivers <!-- optional -->
+
+* [driver 1, e.g., a force, facing concern, …]
+* [driver 2, e.g., a force, facing concern, …]
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* [option 1]
+* [option 2]
+* [option 3] SWC embeds web assembly runtime (https://wasmer.io/), loads plugin built as web assembly.
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: **[option 3] SWC embeds web assembly runtime (https://wasmer.io/), loads plugin built as web assembly.**
+
+This decision is taken because
+- It was relatively easy plugin author to generate single binary works across most of platforms SWC's host binary supports, without concern of cross-target compilations.
+- It was relatively easy to achieve abi-stable between SWC host to plugin binaries.
+- It doesn't require to have separate, specialized AST struct (named `plugin_ast`) to pass into ffi boundary of the plugin.
+- Its serialization / deserialization performance is near identical or faster than `abi_stable` based ffi
+
+## Pros and Cons of the Options <!-- optional -->
+
+### [option 1]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 2]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 3]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+## Links <!-- optional -->
+
+* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
+* … <!-- numbers of links can vary -->

docs/adr/README.md

@@ -0,0 +1,13 @@
+# Architectural Decision Records
+
+This directory contains a series of [Architectural Decision Records](https://adr.github.io/)
+or "ADRs" for the `swc` project. We're going to try to use it as a kind of collective
+memory of the decisions we've made and the path we've taken to get the project to its current
+point.
+
+Note that these are *historical references* that do not supersede (but might enhance) the living
+documentation of the project itself, which you can find inline in the source code.
+
+Proposing a non-trivial change to the way `swc` works? You might like to start with an ADR
+by copying `template.md` into a new file, filling out a first version of the proposal, and
+posting it as a PR on the github repo for discussion.

docs/adr/template.md

@@ -0,0 +1,72 @@
+# [short title of solved problem and solution]
+
+* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
+* Deciders: [list everyone involved in the decision] <!-- optional -->
+* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->
+
+Technical Story: [description | ticket/issue URL] <!-- optional -->
+
+## Context and Problem Statement
+
+[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
+
+## Decision Drivers <!-- optional -->
+
+* [driver 1, e.g., a force, facing concern, …]
+* [driver 2, e.g., a force, facing concern, …]
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* [option 1]
+* [option 2]
+* [option 3]
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+
+### Positive Consequences <!-- optional -->
+
+* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
+* …
+
+### Negative Consequences <!-- optional -->
+
+* [e.g., compromising quality attribute, follow-up decisions required, …]
+* …
+
+## Pros and Cons of the Options <!-- optional -->
+
+### [option 1]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 2]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 3]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+## Links <!-- optional -->
+
+* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
+* … <!-- numbers of links can vary -->