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.
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.
context object with componentDir/workspaceDir. (#1154)getComponentPackageJson.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.require/import calls) dependencies from its JS based configuration files.I will update this issue from time to time until completion.
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.
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.
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:
bit import <bit id>@[version] bit tag <version semver>bit export <new scope name>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.
Most helpful comment
Consider adding the extension API the following function
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