Bit: Compiler extension

[ranm8]

Complete compiler extension.

• [x] make sure all e2e tests after merging branch harmony/compile-tag-hook.
• [x] backward compatibility for legacy compilers. (eventually, "compile" doesn't create capsules, see PR)
• [x] add API to get the task file from the specific compiler. (completed - #2679 )
• [ ] call the extension to write dists on the capsule when the files are modified.
• [x] make sure the example Typescript compiler in react-new-project works.
• [x] fix the configuration workarounds, once #2680 is completed.
• [x] in case of a compilation error using flows, there is no way to catch the error. (waiting for @qballer to fix the last item at https://github.com/teambit/bit/issues/2643. once completed, fix the @todo in the compile.ts file).

API
See src/extensions/compiler/types.ts file.
The complete and updated API is documented in the README.md file of the extension.

Writing dists in the capsule
Note: This spec is not final. Also, it is only about extensions components, not normal components.
When writing an extension component in the capsule Bit should distinguish between two scenarios:

1. a component was not modified since the last tag, or there is no compiler.
   Set writeDists: true to write the dists if they exist while writing the component to the capsule.
2. a component was modified since the last tag, or it's a new component.
   Set writeDists: false to not write any dists. Once the component was written to the capsule, call the compiler to write the dists.

[qballer]

Can we document in this issues at least the API between compile/flows.

[davidfirst]

@qballer , I updated the description with API details. In general, the API is documented in the extension README file.

[ranm8]

@itaymendel I just saw the great progress @davidfirst has been making. Can we prepare a spec for the compile command output? We can do something simple and similar in many ways to what we are doing for flows. Also @qballer might be able to help

[GiladShoham]

One of the props should return the script file (name -> TBD), another prop should return the mainFile.

@ranm8 Aren't the main file should be handled by the add config event?

[ranm8]

@GiladShoham great catch, you are right. This shouldn't be part of the compiler definition. @davidfirst for your attention.

[davidfirst]

Thanks guys, I'll update the description.
The prop for the script file is going to be taskFile, please let me know if you have an objection.

@ranm8 , to get the specific compiler, I call harmony.get('my-specific-compiler'); , I'm able to get the Manifest but with instance: undefined. How do I get the instance?

[ranm8]

Thanks! @davidfirst can you also document the Compiler extension API so we will be in sync re the API, this is the most important thing to be in sync about.
Re access to specific Harmony extension, what is the name of the extension you are trying to access (e.g. name property in the extension manifest)?

[davidfirst]

@ranm8 , Done. I edited the description and added more details.

I'm looking for the instance property.
In my case, the extension name is extensions/gulp-ts. When I call harmony.extensionsIds I see it as extensions/[email protected] (with the version). It might be a bug, not sure.
Anyway, when I call harmony.get('extensions/gulp-ts'); I get the following:

{
  manifest: Extension {
    manifest: {
      name: 'extensions/[email protected]',
      dependencies: [],
      provider: [AsyncFunction: provider]
    },
    _instance: null,
    _loaded: false
  },
  _instance: undefined,
  _loaded: true
}

And harmony.get('extensions/gulp-ts').instance; returns undefined.

[GiladShoham]

@davidfirst I know why this might happen, but I won't have time to help you today.
I'm sure you can debug it and understand what happens. This part of name vs full id is not completely completed on all cases

[ranm8]

@davidfirst It might be a bug I believe I fixed in Harmony and pushed a version just now. Either update @teambit/[email protected] or my PR #2564 to test if it works now.

[davidfirst]

Thanks @ranm8 and @GiladShoham . I'm able to get the instance now. It was my bad (partly related to a failure of an extension during the provide call, which was hard to notice).

In my PR I'm going to change the extension-name to not include the version. So, I could do harmony.get('extensions/gulp-ts'); instead of harmony.get('extensions/[email protected]');.
The change is in the workspace extension:

-        mod.name = id.toString();
+        mod.name = id.toStringWithoutVersion();

Please let me know if we're expecting to have the same extension with different versions, becuase then, we'll need to find another apporach.

[GiladShoham]

@davidfirst of course there will be same extension with different versions.
For example you load few components each of them using the same extension with different version. Harmony store all extensions loaded in the process.

[davidfirst]

@GiladShoham , ok, I'm facing now another issue which is related to the same extension name.
This extension is stored in Harmony as a BitId string: extensions/gulp-ts. However, Flows needs the package-name (@bit/extensions.gulp-ts).
In this compile extension, I need to convert between the two in order to get the extension from Harmony and send the task to Flows.
This conversion is impossible to do without having the bindingPrefix and the defaultScope of the extension component. Loading the ConsumerComponent of the extension doesn't make sense.

I was thinking that Harmony should save all extensions using the package-name. So, I could get my extension from harmony by harmony.get('@bit/extensions.gulp-ts').
However, because we need to support multiple versions of the same extension, it won't be an option anymore.
We'll have to find another way to address this.

[GiladShoham]

It should be the package name with version i guess. We should first implement the enforcement of default scope. And the binding prefix / owner (owner should kind of set the binding prefix for you).
Then we should be able to use this full name everywhere