You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A question we often get asked on forums here and our other support media (slack, email, etc) is "How do I set a package as a devDependency for my bit component?", or "how do I install a package as a devDependency in a Bit workspace?"
Tl;dr
The short answer is - you don't!
Bit's static code analysis detects which of your component's dependencies are used only in dev files such as tests or bit documentation files (.docs.* or .compositions.*) and sets these dependencies as devDependencies for that component.
The Long Answer
A longer answer is required though, because the question asking to be asked is, "Why is Bit different to my other apps?".
And here is the long answer, which might help make that switch from thinking about application-building, to thinking about component or asset building.
You say Dependency, I say devDep
Why is bit different to your other apps? Because with bit you're not building a single app, but many separate mini-apps, or components, each of which has it's own dependency requirements and configurations.
When it comes to installing a component in a bit workspace or project, either via npm/yarn, or via bit's own install function (bit install), it doesn't actually make sense to install the component as a devDependency. Very often, packages can be a regular dependency for one component in a workspace, whilst only being used in dev files of another.
Unlike when dealing with an individual application, whose package.json defines package types for just that app, the package resolution for a bit workspace needs to resolve packages individually for each component in the workspace, and so the decision as to what is a regular dep and what is a devDep needs to be left up to bit, which is set up to do just that.
(Along the same lines, when installing a package in a bit workspace, this package won't now be bundled up in all the components in that workspace. instead, bit will, use the same code analysis per component to determine the actual dependencies of each component, and only those dependencies will make it into the component's package.json file).
So the next time you want to add a dependency that you know is only (currently) used in one of your components' dev files, don't worry - just install it and leave it to bit to decide what type of dependency it is.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Dev Dependencies and Bit
A question we often get asked on forums here and our other support media (slack, email, etc) is "How do I set a package as a devDependency for my bit component?", or "how do I install a package as a devDependency in a Bit workspace?"
Tl;dr
The short answer is - you don't!
Bit's static code analysis detects which of your component's dependencies are used only in dev files such as tests or bit documentation files (.docs.* or .compositions.*) and sets these dependencies as devDependencies for that component.
The Long Answer
A longer answer is required though, because the question asking to be asked is, "Why is Bit different to my other apps?".
And here is the long answer, which might help make that switch from thinking about application-building, to thinking about component or asset building.
You say Dependency, I say devDep
Why is bit different to your other apps? Because with bit you're not building a single app, but many separate mini-apps, or components, each of which has it's own dependency requirements and configurations.
When it comes to installing a component in a bit workspace or project, either via npm/yarn, or via bit's own install function (
bit install
), it doesn't actually make sense to install the component as a devDependency. Very often, packages can be a regular dependency for one component in a workspace, whilst only being used in dev files of another.Unlike when dealing with an individual application, whose package.json defines package types for just that app, the package resolution for a bit workspace needs to resolve packages individually for each component in the workspace, and so the decision as to what is a regular dep and what is a devDep needs to be left up to bit, which is set up to do just that.
(Along the same lines, when installing a package in a bit workspace, this package won't now be bundled up in all the components in that workspace. instead, bit will, use the same code analysis per component to determine the actual dependencies of each component, and only those dependencies will make it into the component's package.json file).
So the next time you want to add a dependency that you know is only (currently) used in one of your components' dev files, don't worry - just install it and leave it to bit to decide what type of dependency it is.
Beta Was this translation helpful? Give feedback.
All reactions