-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Experimental] Presets support #4027
Conversation
@pksunkara, having in mind your work for |
lib/core/src/server/presets.js
Outdated
} | ||
|
||
function getPresets(configDir) { | ||
const presets = serverRequire(path.resolve(configDir, 'presets')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should move to just a single config file called storybook.config.js
which is built out of presets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree, and as I wrote in the Misc ☝️ , it should be a part of the single config file.
However, I don't know what will be implemented/published first. Also, I don't want to create PRs with hundreds of changes in them =)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a warning when using custom presets. It will be only for the presets testing purpose.
lib/core/src/server/presets.js
Outdated
|
||
return { | ||
extendBabel: config => applyPresets(loadedPresets, config, 'extendBabel'), | ||
extendWebpack: config => applyPresets(loadedPresets, config, 'extendWebpack'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you seen https://github.com/mozilla-neutrino/webpack-chain? It would be useful in our architecture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will check this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This package looks interesting. Anyway, we can integrate it later. If we will go with it, it will be a main part of the core, so I would like to here other team members opinion as well =)
lib/core/src/server/presets.js
Outdated
const loadedPresets = loadPresets(presets); | ||
|
||
return { | ||
extendBabel: config => applyPresets(loadedPresets, config, 'extendBabel'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to do this? Can't we somehow merge extendWebpack
and extendBabel
? The webpack-chain I mentioned below should be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's useful to separate different entry points of integration. extendPreview
and extendManager
technically also could be removed 🤷♂️
lib/core/src/server/config.js
Outdated
|
||
const baseConfig = getBaseConfig({ ...options, babelOptions, presets }); | ||
const initialConfig = wrapInitialConfig(baseConfig, configDir); | ||
const config = presets.extendWebpack(initialConfig); | ||
const defaultConfig = wrapDefaultConfig(createDefaultWebpackConfig(config)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should remove these wrappers and rely on presets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the long run - yes (Also wrote about it in Misc). But again, I would like to start using presets, without a huge refactoring in one PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I think we should do is instead of refactoring, we can support the new method of config without changing anything from the first. And once we are happy with the presets, we can remove the old one.
…reset-webpack-custom
# Conflicts: # lib/core/src/server/config/utils.js # lib/core/src/server/config/webpack.config.js # lib/core/src/server/config/webpack.config.prod.js
…k-core-presets # Conflicts: # app/vue/src/server/options.js # lib/core/src/server/config/webpack.config.js
@@ -0,0 +1,72 @@ | |||
/* eslint-disable no-param-reassign,no-shadow */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've opened an issue - neutrinojs/babel-merge#14
In any case, I will move it out of here later.
Looks good! I just have 2 questions.
|
@pksunkara Right now custom presets are kind of a unsupported feature, so I'm find with this for now. In the future I think there should just be a complete list of add presets in the (to be created) unified config file. |
That is what all angular people use =) But, IMO you can bootstrap angular app without any starter, and use SB as well, but there will be more manual work to do |
This PR is good to be merged. I am just trying to see why tests are failing. |
Nevermind, it's been fixed in master. |
Yey 🎆 Work of my life 😭 |
let babelCore = null; | ||
|
||
try { | ||
babelCore = require('@babel/core'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can accidentally resolve to something only accessible from node_modules/@storybook/core/node_modules
not from user's app.
We need to add babel-core
peerDependency and ask users to install bridge if we need to use Babel directly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That what I've tried to prevent, but I assume better to have a peer on a bridge. I will do this after the PR to babel-merge
@igor-dv Why do we need to merge Babel configs on our side? |
I wanted to simplify the API for presets, so apps will also use it. And |
Can you please provide some examples of this pain? I'm just afraid that maintaining a merger can be a greater one (see all the issues with our webpack merger) |
The pain was to consolidate the API between framework, core and custom presets. Take a look in #4107 - where I tried to kill the wrapper. |
This doesn't look too painful to me: |
Issue
presets
is to be able to easily integrate to the different points of SB configuration.Users will be able to combine different presets in their app and create their own.
All official presets will be located in the presets monorepo.
framework-presets
, that will be passed down to thecore
(e.g.framework-preset-vue
)core-prests
(e.g.core-preset-dev
)API
Each preset may expose some of these methods (We can think of more stuff):
Considering
presets.js
(orpresets.ts
) in user's code:Note
presets.js
will be a part of the future single configuration file. For now, when loading a cusomt presets.js file, there will be a warning.We can think of our supported apps as a combination of presets as wellDone