Off Topic > Off Topic
Programming Megathread
Foxscotch:
--- Quote from: Kingdaro on March 01, 2016, 08:55:17 PM ---Just try to make sure you don't spend too much time on your build system more than you do actually making a thing.
--- End quote ---
well, I've already spent quite a lot of time making it, but now I'm at the point where the client scripts are getting too convoluted for me to reasonably keep it all in one file, which is why I need a solution
thanks for showing me that webpack thing, I'll see how it goes~
Kingdaro:
No problem! Also, if anyone tells you that browserify is better, their opinion is wrong.
Like, actually wrong.
Browserify is a bloated mess that I'm so glad I've stepped away from. But I guess it still depends on your goal.
Foxscotch:
I didn't really like the way webpack worked (specifically that I had to concatenate everything before I could test it)
and I figured out that requirejs lets you do it in a way that looks a little more commonjs-y
but NOW I'm having trouble with circular dependencies. I have a UI module that deals with DOM elements, and an out module that deals with sending data to the server, and they rely on each other. the out module has a function that calls a UI function to get some stuff from a text box, but the UI section binds that function to an event listener so that clicking a button will call it
I could VERY EASILY solve this problem by just moving the get-from-text-box bit into the out module's function, but then I'll have stupid DOM code in the out module and if I do THAT then what's the frickin point in splitting it into modules
by the way "Circular dependencies are rare, and usually a sign that you might want to rethink the design."
frick you
I like working with the server side a lot more
maybe I'll just go back to a single file. I wouldn't be having ANY OF THESE PROBLEMS
Ono-Sendai:
--- Quote from: Foxscotch on March 03, 2016, 04:49:21 PM ---I didn't really like the way webpack worked (specifically that I had to concatenate everything before I could test it)
--- End quote ---
webpack works by progressively transforming your data with loaders. it also follows all reference be they js files or actual data resources like images. basically think of your data moving through a pipeline.
here's a webpack config that i made a while ago for something quick. i tend to copy my configs around and modify them. it can be pretty weird at first but webpack can be nice in production environments. it depends if you want to use the grunt/gulp way of doing things or just letting loaders figure it out and adding it to a particular extension's pipeline
ive annotated it a bit so that you hopefully get a feel for some of the things it can do. youre going to have to delve into the docs if you really want to be able to use it on your own but i figure you might be interested is a pseudo-production config
--- Code: ---let webpack = require('webpack'),
path = require('path');
let base_dir = __dirname + '/node_modules/';
let definePlugin = new webpack.DefinePlugin({
__DEV__: JSON.stringify(JSON.parse(process.env.BUILD_DEV || 'true')),
__PRERELEASE__: JSON.stringify(JSON.parse(process.env.BUILD_PRERELEASE || 'false'))
});
// resolve library names in config to js files
function addVendor(name, path) {
if(!config.resolve.alias)
config.resolve.alias = {};
config.resolve.alias[name] = path;
}
let config = {
// where to start the build and what libraries to use
// build a separate vendors bundle so that users can cache your libraries and when your
// code updates they only have to download bundle.js
entry: {
app: ['./src/app/main.js'],
vendors: ['mithril', 'bootstrap', 'jquery', 'bootstrap.css']
},
resolve: {
alias: {
jquery: 'jquery/dist/jquery'
},
root: [path.join(__dirname, 'public/lib')]
},
plugins: [
// names to resolve in the files
new webpack.ProvidePlugin({
$: 'jquery',
jQuery: 'jquery',
m: 'mithril'
}),
// in this config we're not minifying pre-minified js... you could minify and dedupe the non-minified production versions
// of these libraries and potentially get a smaller bundle.js size but builds take longer
new webpack.optimize.CommonsChunkPlugin('vendors', 'vendors.js')
// new webpack.optimize.UglifyJsPlugin(),
// new webpack.optimize.DedupePlugin()
],
// where to output the build bundle.js
output: {
path: './public',
filename: 'bundle.js'
},
module: {
noParse: [],
// loaders to transform files with certain file extensions read from right to left. data pipelines steps are separated with !
loaders: [
{
test: /\.js$/,
exclude: [/node_modules/, /public/],
loader: 'babel',
query: {
presets: ['es2015']
}
},
// use msx-loader to transform mithril jsx-like files you can see options being passed to this particular loader
{ test: /\.msx$/, loader: "msx-loader?harmony=true&precompile=true"},
// sass-loader -> css-loader -> style-loader
{ test: /\.scss$/, loader: "style-loader!css-loader!sass-loader"},
{ test: /\.css$/, loader: "style-loader!css-loader" },
{ test: /\.png$/, loader: "file-loader" },
{ test: /\.(woff|woff2)$/, loader: "url-loader?limit=10000&mimetype=application/font-woff" },
{ test: /\.ttf$/, loader: "file-loader" },
{ test: /\.eot$/, loader: "file-loader" },
{ test: /\.svg$/, loader: "file-loader" }
]
},
// require('name') without extensions will automatically get files with name.[ext] where [ext] is one of the named extensions
resolve: {
extensions: ['', '.js', '.json', '.msx']
}
};
// add vendor files and provide names.
addVendor('jquery', base_dir + 'jquery/dist/jquery.min.js');
addVendor('mithril', base_dir + 'mithril/mithril.min.js');
addVendor('bootstrap', base_dir + 'bootstrap/dist/js/bootstrap.min.js');
addVendor('bootstrap.css', base_dir + 'bootstrap/dist/css/bootstrap.min.css');
module.exports = config;
--- End code ---
you can do way more with it but its really good for large scale projects. this is kind of a messy way to handle css but it works for this config i guess. in the end theres no good build system for real web applications but you need them to handle the complexity of large applications.
oh yeah webpack_dev_server is really cool you should check that out. its kinda like nodemon
--- Quote from: Kingdaro on March 01, 2016, 09:17:32 PM ---No problem! Also, if anyone tells you that browserify is better, their opinion is wrong.
Like, actually wrong.
Browserify is a bloated mess that I'm so glad I've stepped away from. But I guess it still depends on your goal.
--- End quote ---
it depends on what you want to do. right tool for the right job. i think browserify is alright actually
--- Quote from: Foxscotch on March 03, 2016, 04:49:21 PM ---maybe I'll just go back to a single file. I wouldn't be having ANY OF THESE PROBLEMS
--- End quote ---
if that works for you, thats great. it depends on how big your application is
Ono-Sendai:
oh and if you want sourcemaps to debug you can do that. its a really important part that i left out because they are definitely needed for serious development. chrome's inspector works quite nicely with them
i made my previous post because webpack doesnt need to do what you specified. its extremely flexible albeit confusing at first. i think it definitely is the most workable build solution but it depends on how much mental energy you want to sink into it