Bit: New compilers/testers environments

Created on 28 Jul 2018  路  9Comments  路  Source: teambit/bit

This issue tracks the required changes in bit in order to support the new set of environments. Contributors/Community are more then welcome to comment.

Background

Bit uses a special group of extensions in order to test and compile components. Our current set of extensions is developed in teambit/bit.envs and they have provided a vital service. The issue with current toolset is that its configuration is hard coded. This encourages users of Bit to fork the compilers and make very small changes which leads to code duplication. We are in the process to create abstract extensions which will be able to support (hopefully) many if not most use cases. While the main bulk of the work is being done in teambit/bit-envs, this ticket will track extension API changes required in bit.

What is needed

  1. Every extension API call should get a context object with componentDir/workspaceDir. (#1154)
  2. API object should have a function getComponentPackageJson
  3. Consider having an API call to perform relative require. The require function should be called within a file in the componentDir. This is to "hit" the component node_modules first and not the extension. Current implementation assumes bit will ignore .bitTmp folder. This folder will be created in the component directory dynamically and will contain code which will require modules from the component node_modules. Implementing this in bit will also assist in case the extension throws an exception and fails to cleanup after itself. Even without the api bit status, bit diff etc should ignore changes in this folder.
  4. Bit should deduce the explicit (require/import calls) dependencies from its JS based configuration files.

I will update this issue from time to time until completion.

areextensions typfeature

Most helpful comment

Consider adding the extension API the following function

getDefaultConfiguration(): Object;

this function should return a default configuration for the compiler entry in bit JSON to populate. This will allow easy on boarding for envs and save user time. The result of this function should populate the compiler entry if there is a string there or a different compiler is being used.

cc: @GiladShoham

All 9 comments

Compiler/Tester init api call will return an Options object which looks as following:

{
  write:boolean
}

This means that the env needs access to the filesystem of the component. In the future other options may be added.

Right now testers will return flatten results, this needs to change in order to support hierarchy of results. For that Bit needs to change it's raw expected result. Relates to https://github.com/teambit/bit-envs/issues/10

Still considering it, but for typescript support we will need the original(author) or the component (both?) package.json in the getDynamicPackageDependencies API to understand the types.

  1. there is no support to adding files to the component that shouldn't be compiled. This can be supported in bit or that env developers should copy the file to the right now location.

  2. For typescript support we will need custom dependencies resolution to resolve custom types.

Consider adding the extension API the following function

getDefaultConfiguration(): Object;

this function should return a default configuration for the compiler entry in bit JSON to populate. This will allow easy on boarding for envs and save user time. The result of this function should populate the compiler entry if there is a string there or a different compiler is being used.

cc: @GiladShoham

Hi @qballer,
Could you update us on progress?
I'm in dire need of outputting definition files so that I can share typescript modules across my projects.
Thanks!

@PatrickGeyer, we have updated the bit ts compiler to spit out definition files. but it might be slow. I would suggest trying it out.

how to edit current environments (compilers/testers), for users trying to use a custom compiler settings:

  1. Import the env as a regular component: bit import <bit id>@[version]
  2. make your local changes.
  3. tag a new version of the component bit tag <version semver>
  4. export to your own scope: bit export <new scope name>
  5. re import the compiler as an env: bit import <new bit id from scope> <-t/-c> -c for compiler -t for tester.

In order to debug your current changes without exporting you should change the bit.json in the author environment. You will need to add the compiler (tester if you are editing one) entry into and object which looks as following :

Before:

{
  "env": {
    "compiler": "bit.some-scope/[email protected]"
  },
  "dependencies": {},
  "componentsDefaultDirectory": "components/{name}",
  "packageManager": "npm"
}

After:

{
  "env": {
    "compiler": {
      "bit.some-scope/[email protected]": {
        "options": {
          "file": "/<local path to compiled/vanilla JavaScript>/dist/src/compiler.js
        }
      }
    }
  },
  "dependencies": {},
  "componentsDefaultDirectory": "components/{name}",
  "packageManager": "npm"
}

This issue refers to a suggested new API for the compilers / testers.
We have extended the scope of the compiler / testers API to a full extensions API.
It will be handled under a new issue.
Closing this, it's not relevant anymore.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AmitFeldman picture AmitFeldman  路  22Comments

itaymendel picture itaymendel  路  10Comments

itaymendel picture itaymendel  路  16Comments

AlexanderKaran picture AlexanderKaran  路  10Comments

nvthuong1996 picture nvthuong1996  路  13Comments