Suggested structure for component and its capsule.

[Tallyb]

The following is the structure suggested for a component that is built using a capsule. This format is applicable for folder-based components only (whole folder).

Inside the project - the component contains the source and dev files.
In addition - a bit.json (jsonc? same same) file may reside to include instructions for Bit. Pacakge.json cannot reside inside this folder, as it is a file generated by Bit.

When building the capsule the following format occurs:

pacakge.json (generated by bit)
Additional configuration files on the root (e.g. tsconfig) depending on the extensions used etc.
src (folder)
  |-- sources & dev files 
dist 
  |-- all dist files. potentially with subdirectories. 
(potentially a mock folder will be needed for testing purposes)

The bit.json file inside the folder is copied to the root and can include instructions to bit on generating package.json(e.g. addition and removal of dependencies), tsconfig options, etc.
Although it is possible to write explicit instructions per component, the expectation is to have most of the configuration on the workspace level with overrides syntax and not on each component separately.

Benefits of storing source files in an src folder and not in capsule root:

• easier for configuration, as there is no collision with configuration files which might be a js / ts files. So you can apply things like linting only on the code itself.
• src folder can be symlinked in a capsule directly (i.e. src in capsule -> WS folder. So you get all file changes inside)
• Reduce the chance for collisions with other folders. E.g. if the user has decided to have a dist folder in his code.

[GiladShoham]

Just to make sure I understand correctly.
So in the workspace, it will look something like this?

.
└── components
    └── my-comp
        ├── bit.jsonc
        └── index.js

And my-comp-capsule/src is symlinked to components/my-comp?
I know @ranm8 doesn't like the idea of creating bit.json in the component folder, he prefers package.json.
Also I'm not sure we can gather stuff like the tsconfig. since it's not part of the component but part of the extension. (the component itself isn't even aware of such file)
Which lead me to try to think what if I have a ts compiler used by many components in my ws, and I want to change its tsconfig only for one of them, how can I achieve this with a proper UX?
If I import the compiler, change its tsconfig, it will affect everything.

@ranm8 @itaymendel @davidfirst @imsnif
I would love to hear your feedback on this.

[Tallyb]

@GiladShoham - yes. this is the structure.
I do not like having a package.json that is merged into the "real" package.json in some convoluted logic (we ignore this, override that, and merge the 3rd one.
Package.json is a "reserved" name. We should not interfere with it, and we also have limited control as to what can be done there. Unless of course, the "bit" section, which is the equivalent of having a bit.json file.

[GiladShoham]

I do not like having a package.json that is merged into the "real" package.json in some convoluted logic (we ignore this, override that, and merge the 3rd one.

I tend to agree, convince @ranm8 about it.

[itaymendel]

Bit does not interfere with the package.json.There's no intention to enforce anything on that file whatsoever. There's no convoluted logic. If something's in the package.json - nothing can change it, only the user.

[Tallyb]

@itaymendel - not main? not version? not types? not other entries (es2015)? not dependencies? You expect the user to provide everything including versions update?

[GiladShoham]

After a long discussion, we decided to change it to component.json.
It will be documented under another issue.

[davidfirst]

@GiladShoham , I just came across another use-case where having the source inside a directory "src" could help.
When creating the capsule, we might have two package.json files. One of them is saved in a different dir that should not be treated as a source file. This happens when we want the package.json to have the dependencies with dummy versions where they're new but we don't want the package-manager to fail because of them.

Anyway, regardless, I tend to agree with the suggestion of having this src directory in the capsule.

[GiladShoham]

@davidfirst I understand how it might help for this, but I won't take it as a consideration when coming to decide about the structure. It's not a strong enough reason. just a side bonus

[davidfirst]

@GiladShoham , that's correct, we're actually not going to write them both. The point is that we might find ourselves in a need for writing files that are not related to the source.

[davidfirst]

I'm working on the watch extension, and some of the challenges I'm having could be resolved by adapting the structure above.
The main challenge is the performance of "bit watch".
According to the specs of #2677 , there is a running tsc -w process on the capsules. Once a file is changed on the workspace, watch extension re-load the component, which triggers a re-write of the capsule, which triggers tsc -w process to compile the changed files.
The problem is that tsc -w doesn't perform well when rewriting multiple files at once.
It's better to rewrite only the changed files to the capsule. (to be precise, the tsc -w process takes 21 seconds to complete, instead of 2.5 seconds when only one file is changed directly).
There are two ways to achieve this according to the structure above:

1. having all source files in the src dir. This way, it's easier to compare the component files on the workspace to the files in the capsule. Otherwise, we'll have to figure out what files in the capsule are internal configuration and what are the source files.

2. symlink the "src" in the capsule to the workspace. This is an interesting idea. Implementing this will improve the watch performance dramatically because then, there is no need for Bit intervention. The tsc -w process gets the changes immediately and compiles the files. No need to write anything to the capsule manually.

Another issue I'm having is when running bit watch then, bit compile then bit watch again, it shows an error error TS5055: Cannot write file '/Users/username/Library/Caches/Bit/capsules/4ff44c81b43ba7bd510274165d0509db76ae43db/bit.core_workspace@0.0.5/dist/index.d.ts' because it would overwrite input file., although I added dist dir as excluded. This will probably be fixed once the tsconfig is set to include only files on "src" dir.

@ranm8 , @GiladShoham , what do you think?

[davidfirst]

To keep this issue up to date. I tried a POC in the branch above and it didn't work well. See more details in this comment: #2677 (comment).

[GiladShoham]

@davidfirst I believe we can close it already? please re-open if you think we need further discussion about it.

[GentleProgramist]

I have error such as above picture.