Added new helper functions to server.js. Ribbit now 'installs' (creates a symlink to) the user's dependencies and generates a custom webpack config based on the settings specified in the user's ribbit config.
How?
linkUserDeps and unlinkUserDeps
linkUserDeps 'installs' the dependencies specified in the user's ribbit config by sym-linking them from the user's node_modules folder. This means we can remove babel-loader and a few other dependencies from Ribbit! =D
unlinkUserDeps removes the symlinks generated by linkUserDeps.
genWebpackConfig
genWebpackConfig generates a webpack config using the settings the user specifies in their ribbit config. The output field libraryTarget: 'commonjs' is currently hardcoded to what it was previously, but can be changed once we move to a plugin-based architecture. Entry point(s) is/are still specified through the CLI command generated by buildRoutesCliCommand, as it was previously.
Testing
Run ribbit init inside our current demo app.
Add to the dependencies property in ribbit config. This is an array of strings listing the name of each dependency. For our demo app, we would have to add babel-loader.
Add to the webpackSettings property in ribbit config. This is a list of rules and other settings you would want to use.
Add to the the rest of the ribbit config as necessary.
Run ribbit build!
Request for Feedback
Please test with other web apps you have lying around.
Code review, and any suggestions on what we should change with these helpers.
Currently, linkUserDeps depends on the user already having installed the dependencies they listed in their ribbit config. Is this too much of an ask? Should we also automatically install any packages that they listed as dependencies but have not installed themselves?
What?
Added new helper functions to server.js. Ribbit now 'installs' (creates a symlink to) the user's dependencies and generates a custom webpack config based on the settings specified in the user's ribbit config.
How?
linkUserDeps and unlinkUserDeps
genWebpackConfig
libraryTarget: 'commonjs'
is currently hardcoded to what it was previously, but can be changed once we move to a plugin-based architecture. Entry point(s) is/are still specified through the CLI command generated by buildRoutesCliCommand, as it was previously.Testing
Request for Feedback