Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL

Thermopyle posted:

What stage Babel transpilation does it do?

The problem with removing configuration is that...there are things people commonly want to configure!

Looks like react, es6, es7, and a few other plugins that aren't standards yet: https://github.com/facebookincubator/create-react-app/blob/master/config/babel.prod.js

I think their reasoning is that it's simpler to have no config or let you go totally custom at first, rather than trying to anticipate what kinds of customization people might want to add. They're going to continue refining it, though so we may see more presets down the line.

Adbot
ADBOT LOVES YOU

Xik
Mar 10, 2011

Dinosaur Gum
I don't think I replied earlier, but I appreciate the responses I got about weaknesses of Angular. Our first (and possibly second) major application rewrite will be using Angular 1.5 with Typescript on the front-end so I'll be passing on some of the provided links to the team.

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

Xik posted:

I don't think I replied earlier, but I appreciate the responses I got about weaknesses of Angular. Our first (and possibly second) major application rewrite will be using Angular 1.5 with Typescript on the front-end so I'll be passing on some of the provided links to the team.

A lot of the architectural weaknesses of Angular can be worked around quite well using 1.5 and TypeScript. You can get quite close to something that you could easily port to Angular 2 or Aurelia later on if you are strict about it.

Plavski
Feb 1, 2006

I could be a revolutionary
Aurelia 1.0 shipped: http://blog.durandal.io/2016/07/27/aurelia-1-0-is-here/

The Merkinman
Apr 22, 2007

I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!
Wow, no action for over a week on this thread?

I've asked before about Gulp, Grunt, etc. If I were to start using them (I still don't know why I would) do I need to make a new site entirely from scratch or could a web site be slowly updated, page by page, to use it?

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

The Merkinman posted:

Wow, no action for over a week on this thread?

I've asked before about Gulp, Grunt, etc. If I were to start using them (I still don't know why I would) do I need to make a new site entirely from scratch or could a web site be slowly updated, page by page, to use it?

Skip them and use webpack or plain npm scripts :v:

They *why* is because you want to perform build step from the time you hit 'save' to the time code gets to the browser. For example, when I save a file, webpack:

  • looks at the entry point of my code and gathers up all the imports for me into just what's used
  • transforms my ES6 to "vanilla" js
  • transforms my SASS into css
  • pulls out just the CSS that's actually used
  • autoprefixes that css
  • separates out all my "vendor" code (React, d3, whatever) into a separate file so it can be cached (in production)
  • minifies everything.
  • writes a new index.html for me with all the SCRIPT and LINK tags for the js /css
  • hot reloads my browser (in dev)

Plus probably a bunch of other stuff I forget.

If you write "raw" JS and CSS, then you don't really need that stuff.

The Merkinman
Apr 22, 2007

I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Lumpy posted:

Skip them and use webpack or plain npm scripts :v:

They *why* is because you want to perform build step from the time you hit 'save' to the time code gets to the browser. For example, when I save a file, webpack:

  • looks at the entry point of my code and gathers up all the imports for me into just what's used
  • transforms my ES6 to "vanilla" js
  • transforms my SASS into css
  • pulls out just the CSS that's actually used
  • autoprefixes that css
  • separates out all my "vendor" code (React, d3, whatever) into a separate file so it can be cached (in production)
  • minifies everything.
  • writes a new index.html for me with all the SCRIPT and LINK tags for the js /css
  • hot reloads my browser (in dev)

Plus probably a bunch of other stuff I forget.

If you write "raw" JS and CSS, then you don't really need that stuff.
Thank you so much for that list.
Our JS is pretty raw, utilizing a lot of jQuery... though we just started using Angular 2.0 (typescript, requirejs) for part of our site.
I already have SCSS to CSS through some compass command thing that I don't even remember how I set up.

So, in general
Is all of this only really useful in DEV, and production wouldn't matter, or it's beneficial there too?
Would I need to start a whole new site-wide rebuild of the entire site to utilize this or could I update as I go (which I was able to do with the SCSS -> app.css workflow)

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

The Merkinman posted:

Thank you so much for that list.
Our JS is pretty raw, utilizing a lot of jQuery... though we just started using Angular 2.0 (typescript, requirejs) for part of our site.
I already have SCSS to CSS through some compass command thing that I don't even remember how I set up.

So, in general
Is all of this only really useful in DEV, and production wouldn't matter, or it's beneficial there too?
Would I need to start a whole new site-wide rebuild of the entire site to utilize this or could I update as I go (which I was able to do with the SCSS -> app.css workflow)

It's useful in both dev and production. I have a webpack config for dev (with hot reloading, source maps, etc.) and one for production (file splitting, extracting CSS to files, minify, etc.)

If you are using Angular 2, you'll need a transpiling step (typescript -> plain JS) already so, you can use npm / webpack to do that for you along with your SASS stuff all in one go. You can use these build tools either as glorified script runners (do SASS, then .ts, then...) or use them to for fancy stuff like bundle splitting and so on, so you can easily start on the simple side then add more stuff as you want.

dupersaurus
Aug 1, 2012

Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

The Merkinman posted:

Thank you so much for that list.
Our JS is pretty raw, utilizing a lot of jQuery... though we just started using Angular 2.0 (typescript, requirejs) for part of our site.
I already have SCSS to CSS through some compass command thing that I don't even remember how I set up.

So, in general
Is all of this only really useful in DEV, and production wouldn't matter, or it's beneficial there too?
Would I need to start a whole new site-wide rebuild of the entire site to utilize this or could I update as I go (which I was able to do with the SCSS -> app.css workflow)

I've been using webpack on my Angular 2 app, and when packaged and minified, it dropped a couple of MB off the total production download size (my code + my templates + Angular code), and put everything in four files. And since webpack goes through the dependency tree itself, I don't have to manually order the ts files in tsconfig.

HaB
Jan 5, 2001

What are the odds?
Quick question on the best way to handle this:

I have a large data file full of cities, along with country info, lat/long, etc. It's some 210k lines of JSON.

19.2 megs to be precise. Is there a good way to load that into memory on a node service and search it? Or would I be better off dumping it into a database?

I was trying to avoid databases altogether for the sake of simplicity, but this is the ONE use-case in favor of it.

I am using hapi, so I will be able to cache lookup responses, but I'm not sure how much that will save me anyway, since I doubt my userbase is going to be significant enough for the caching to come into play.

Will also accept: some sort of FREE webservice I can use to do this. I am using openweather's api, and they prefer weather lookups by city Id, which is where the datafile came from. Problem is - on their free plan I am only allowed 60 requests per minute, so I'd rather not do one for the city lookup, then one for the weather itself.

Suggestions?


TIA.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

HaB posted:

Quick question on the best way to handle this:

I have a large data file full of cities, along with country info, lat/long, etc. It's some 210k lines of JSON.

19.2 megs to be precise. Is there a good way to load that into memory on a node service and search it? Or would I be better off dumping it into a database?

I was trying to avoid databases altogether for the sake of simplicity, but this is the ONE use-case in favor of it.

I am using hapi, so I will be able to cache lookup responses, but I'm not sure how much that will save me anyway, since I doubt my userbase is going to be significant enough for the caching to come into play.

Will also accept: some sort of FREE webservice I can use to do this. I am using openweather's api, and they prefer weather lookups by city Id, which is where the datafile came from. Problem is - on their free plan I am only allowed 60 requests per minute, so I'd rather not do one for the city lookup, then one for the weather itself.

Suggestions?


TIA.

sqlite or mongo

Horn
Jun 18, 2004

Penetration is the key to success
College Slice
Is this for work or fun? If it's for work then I agree with Lumpy, get a DB. If its for fun you can rely on node's module caching and just wrap the blob of data with a thin web service.

Kobayashi
Aug 13, 2004

by Nyc_Tattoo
I'd just do SQLite, you can npm install it without anything else and use something like ORM2 to avoid actual SQL.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice
I came across this and thought I'd share: I Peeked Into My Node_Modules Directory And You Won’t Believe What Happened Next

I'm not sure what is funnier, the article or the comments from people who think it's real..... :v:

HaB
Jan 5, 2001

What are the odds?

Lumpy posted:

I came across this and thought I'd share: I Peeked Into My Node_Modules Directory And You Won’t Believe What Happened Next

I'm not sure what is funnier, the article or the comments from people who think it's real..... :v:

I got linked this earlier today, and it did take a few minutes before I realized it wasn't real. Node dev these days is such that it wouldn't have surprised me to find stuff like that hot pocket tweet embedded somewhere in the module tree. That thing is a nightmare.

A good chuckle from the article, tho.

Kekekela
Oct 28, 2004

Lumpy posted:

Skip them and use webpack or plain npm scripts :v:
Seconding this approach. I think if you're coming from including javascript files via script tags, the first big "why" is module support.

crazysim
May 23, 2004
I AM SOOOOO GAY

Lumpy posted:

I came across this and thought I'd share: I Peeked Into My Node_Modules Directory And You Won’t Believe What Happened Next

I'm not sure what is funnier, the article or the comments from people who think it's real..... :v:

It appears that some of it has been made real though!

https://github.com/babel/babel/commit/f36d07d30334f86412a9d2771880cb566a82a9b6



And there's nothing you can do about it.

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
the best part is him trying to count lines

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me
My favourite was his "IF all human history could fit into a megabyte, then this library is SEVENTEEN times what it would take to store all of human history", and then all the comments which doubted the validity of fitting all of history in a single megabyte. Priceless

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

crazysim posted:

It appears that some of it has been made real though!

https://github.com/babel/babel/commit/f36d07d30334f86412a9d2771880cb566a82a9b6



And there's nothing you can do about it.

hahaha one of the comments on the commit:

quote:

You idiots! This is 186 lines long! If all of babel could fit on one line, this would be 186 times bigger than babel itself!! (Or 186% bigger!!)

xpander
Sep 2, 2004
I'm writing a web app comprised of a frontend with Ember, and a backend with Flask. Currently I have the Ember app in a subfolder of the main project directory. I am about to do the initial git commit, and I'm wondering if I'm better off moving the Ember app into its own project folder and git repo. Any suggestions or comments in this regard?

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

xpander posted:

I'm writing a web app comprised of a frontend with Ember, and a backend with Flask. Currently I have the Ember app in a subfolder of the main project directory. I am about to do the initial git commit, and I'm wondering if I'm better off moving the Ember app into its own project folder and git repo. Any suggestions or comments in this regard?

Yes, you should have the front and back end in totally separate repos. That's my opinion obviously, but since (hopefully) the two projects aren't coupled, there is no reason to have to pull down the entire backed to make a change to the front end. There are places that do "one giant repo for everything " but I forget the reasoning for that. Not that it was be, I just can't remember.

Kobayashi
Aug 13, 2004

by Nyc_Tattoo
Kind of a shot in the dark here, but does anyone use Selenium (or some front end for Selenium) for functional testing? And if so, tried to do full page screenshots? Apparently there's some years-old bug in Chrome webdriver that makes this not work. But Firefox and Phantom have their own issues. Like, surely mine isn't the only company in the world that wants to screenshot functional tests on a wide range of browsers (including mobile). Can someone point me at the right Google terms?

M31
Jun 12, 2012

Lumpy posted:

Yes, you should have the front and back end in totally separate repos. That's my opinion obviously, but since (hopefully) the two projects aren't coupled, there is no reason to have to pull down the entire backed to make a change to the front end. There are places that do "one giant repo for everything " but I forget the reasoning for that. Not that it was be, I just can't remember.
But for a lot of projects, the front and backend are incredibly coupled from a functional perspective, which is the main reason you want them in one repository (often changes will require work on both the front and back).

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.

M31 posted:

But for a lot of projects, the front and backend are incredibly coupled from a functional perspective, which is the main reason you want them in one repository (often changes will require work on both the front and back).

Yeah. Many of my projects are built with a couple of subdirectories in the repo rather than git repos. Early in a project, and often even later than that, feature commits will usually need changes on both front and backend to be sensible.

Splitting early can add unnecessary overhead to deploying in a lot of cases. As long as the front end and backend aren't sharing code in terrible ways a split should not be hard to achieve down the track.

an skeleton
Apr 23, 2012

scowls @ u

Kobayashi posted:

Kind of a shot in the dark here, but does anyone use Selenium (or some front end for Selenium) for functional testing? And if so, tried to do full page screenshots? Apparently there's some years-old bug in Chrome webdriver that makes this not work. But Firefox and Phantom have their own issues. Like, surely mine isn't the only company in the world that wants to screenshot functional tests on a wide range of browsers (including mobile). Can someone point me at the right Google terms?

I worked on some integration testing before that used Selenium and Protractor. It seemed to work OK with your usual smattering of bugs due to browser/dependency issues.

xpander
Sep 2, 2004
Thanks for the weigh-in guys. I just realized I have to rewrite something, caused by using RESTAdapter instead of JsonAPIAdapter-clutchin' like I should. Because these projects are generally coupled, I think I'll keep them in the same repo for the moment. I'll break out the frontend if that ever makes sense in the future.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

M31 posted:

But for a lot of projects, the front and backend are incredibly coupled from a functional perspective, which is the main reason you want them in one repository (often changes will require work on both the front and back).

If that's the case, then sure. I was thinking of the "modern front end " style of the backend being only exposed as an API and isn't coupled in any way to the front. I guess if your API changes though....

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.

Lumpy posted:

If that's the case, then sure. I was thinking of the "modern front end " style of the backend being only exposed as an API and isn't coupled in any way to the front. I guess if your API changes though....

Even if you're using 'modern' front end, many projects take a fair while before a feature can be developed and deployed on the front end completely independent of the back end, or vice versa. It can make sense to test and deploy them as a singular unit during this time.

lunar detritus
May 6, 2009


Lumpy posted:

If that's the case, then sure. I was thinking of the "modern front end " style of the backend being only exposed as an API and isn't coupled in any way to the front. I guess if your API changes though....

If your API is not versioned I'm pretty sure you're doing it wrong.

But yeah, if your frontend is a couple of views in Rails' assets folder, sure, keep everything in the same repo. If your frontend is a bonafide API client and you want to keep it that way it should have its own repo, otherwise it just breeds laziness.

EDIT: I mean laziness in the "Oh, let's just pass those values through the templating system". I mean, that's not inherently bad but it stops being a pure client. It all depends on your development process anyway.

lunar detritus fucked around with this message at 06:25 on Aug 15, 2016

Feral Integral
Jun 6, 2006

YOSPOS

Kobayashi posted:

Kind of a shot in the dark here, but does anyone use Selenium (or some front end for Selenium) for functional testing? And if so, tried to do full page screenshots? Apparently there's some years-old bug in Chrome webdriver that makes this not work. But Firefox and Phantom have their own issues. Like, surely mine isn't the only company in the world that wants to screenshot functional tests on a wide range of browsers (including mobile). Can someone point me at the right Google terms?

driver.get_screenshot_as_file('/tmp/google.png') doesn't work? I don't have to take screenshots, but I've had other issues with the chromedriver in the past.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Yeah, I think if your site is a client to your backend it should be a separate project.

Keeping them under the same roof breeds shortcuts that leads to tight coupling.

Xik
Mar 10, 2011

Dinosaur Gum
For me it would be separate repos.

At home (git):
I feel it is less mental overhead to think of the git repository as a "compartment". I just call it the "github model" because the way their web interface is designed encourages this way of doing it. You have the linter config, gitignore, README, build script etc in the root of the repo. You can then open the directory in a modern text editor and have it all be nice and contained.

I also like how the entire git log stays specific for this project.

At work (svn):
We follow SVN recommendations and have the typical trunk, branches, tags subfolders for each project*.
In every single case we would have the web API be a completely separate project/"repo" from the front end. This is mostly to fit in with how the organization manages IT projects. The developers that work on the API might be completely different to the ones doing the front end application or more commonly, the projects would be upgraded/expanded/replaced at different times.

*In saying that, there is technically nothing stopping any of us from doing a checkout of the root folder and work on it as a single "repo" (except maybe workstation storage constraints now that we have SSDs).

HaB
Jan 5, 2001

What are the odds?
Any webpack gurus around?

I am setting up a project in it, and it's my first time, and I don't understand some things. Google is only being semi-helpful at this point.

What I want:

- EVERYTHING moved to a /public folder on build
- js built into bundle.js
- scss/css built into site.css
- dev server reloading all changes automagically

What I got (aside from lovin')

- bundle.js created in /public (yay!)

The problems:

- dev server does in fact rebuild the bundle, and site.css and moves them to the apropos directory. But I see no changes in the browser. Even if I manually clear cache / reload. So for now, I run the dev server in one terminal and webpack in a different one. After running just a plain build with webpack, refreshing shows my changes. Annoying as poo poo, from a workflow perspective.

- my index.html is in my src folder, which contains public. I want the index.html to be moved to public on build. I think I am probably just missing the loader to do that.

My webpack.config:

pre:
const webpack = require('webpack');
const path = require('path');
const ExtractTextPlugin = require('extract-text-webpack-plugin');

const BUILD_DIR = path.resolve(__dirname, 'src/public');
const APP_DIR = path.resolve(__dirname, 'src/app');

const config = {
    entry: APP_DIR + '/index.jsx',
    output: {
        path: BUILD_DIR,
        filename: 'bundle.js'
    },
    module: {
        loaders: [
            {
                test: /\.jsx?/,
                include: APP_DIR,
                loader: 'babel'
            },
            {
                test: /\.css$/,
                loader: ExtractTextPlugin.extract(["style", "css"])
            },
            {
                test: /\.scss$/,
                loader: ExtractTextPlugin.extract(["css", "sass"])
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin('site.css', {
            allChunks: true
        })
    ]
};

module.exports = config;
So yeah - I'm pretty webpack stupid, since this is the first time I have actually configured it myself. Suggestions are welcomed.

Depressing Box
Jun 27, 2010

Half-price sideshow.

HaB posted:

- dev server does in fact rebuild the bundle, and site.css and moves them to the apropos directory. But I see no changes in the browser. Even if I manually clear cache / reload. So for now, I run the dev server in one terminal and webpack in a different one. After running just a plain build with webpack, refreshing shows my changes. Annoying as poo poo, from a workflow perspective.

Did you enable automatic refresh? Running dev server with --inline is the quickest way.

HaB posted:

- my index.html is in my src folder, which contains public. I want the index.html to be moved to public on build. I think I am probably just missing the loader to do that.

You could use file-loader and require index.html directly in your scripts, or have webpack generate the HTML itself (which also supports templates).

HaB
Jan 5, 2001

What are the odds?

Depressing Box posted:

Did you enable automatic refresh? Running dev server with --inline is the quickest way.


You could use file-loader and require index.html directly in your scripts, or have webpack generate the HTML itself (which also supports templates).

I added --inline and --hot to my command line, and now the browser does auto refresh, but css changes still don't show up.

I will give the file loader thing a try. For now that poo poo's way secondary to the css problem, because I'm not a great css guy, so my technique is "sit there and jack with it until I get what I want" and that's a pain when changes don't automatically show up.

Depressing Box
Jun 27, 2010

Half-price sideshow.

HaB posted:

I added --inline and --hot to my command line, and now the browser does auto refresh, but css changes still don't show up.

That's probably because of ExtractTextPlugin, which extracts chunks from the bundle (which also means they won't be reloaded when the bundle is).

I found a discussion about a similar issue and the general recommendation was to treat ExtractTextPlugin like a production optimization for style-loader, which is compatible with hot reloading.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

HaB posted:

Any webpack gurus around?

I am setting up a project in it, and it's my first time, and I don't understand some things. Google is only being semi-helpful at this point.

What I want:

- EVERYTHING moved to a /public folder on build
- js built into bundle.js
- scss/css built into site.css
- dev server reloading all changes automagically

What I got (aside from lovin')

- bundle.js created in /public (yay!)

The problems:

- dev server does in fact rebuild the bundle, and site.css and moves them to the apropos directory. But I see no changes in the browser. Even if I manually clear cache / reload. So for now, I run the dev server in one terminal and webpack in a different one. After running just a plain build with webpack, refreshing shows my changes. Annoying as poo poo, from a workflow perspective.

- my index.html is in my src folder, which contains public. I want the index.html to be moved to public on build. I think I am probably just missing the loader to do that.



So yeah - I'm pretty webpack stupid, since this is the first time I have actually configured it myself. Suggestions are welcomed.

Have two configs. One for dev / hot reload (since dev server serves from memory) and one for build / prod (since that will put files places)

Here's my dev config. It uses an index.html file in project root that just has a script tag for bundle.js and the root DIV. This is fine, since in dev all js and css are all mushed up together.

JavaScript code:
// webpack.config.js
const path    = require('path');
const webpack = require('webpack');
const autoprefixer = require('autoprefixer')

const sassLoaders = [
    'style-loader',
    'css-loader',
    'postcss-loader',
    'sass-loader?includePaths[]=' + path.resolve(__dirname, './src')
]

module.exports = {
    entry:  [
        'webpack-dev-server/client?[url]http://127.0.0.1:8080/[/url]',
        'webpack/hot/only-dev-server',
        './src/client.js'
    ],
    output: {
        publicPath: "/",
        path:     __dirname,
        filename: 'bundle.js',
    },
    resolve: {
        modulesDirectories: ['node_modules', 'shared'],
        extensions:         ['', '.js', '.jsx']
    },
    module: {
        noParse: [/moment.js/],
        loaders: [
            {
            test:    /\.jsx?$/,
            exclude: /node_modules/,
            loaders: ['react-hot', 'babel']
        },
        {
            test: /\.scss$/,
            loaders: sassLoaders
        },
        { 
            test: /\.(png|jpg)$/,
            loader: 'file-loader?name=[path][hash].[ext]' 
        },

        ]
    },
    plugins: [
        new webpack.HotModuleReplacementPlugin(),
        new webpack.NoErrorsPlugin()
    ],
    devtool: 'inline-source-map',
};

I use a devServer file to actually run my dev envionment (with node devServer.js):

JavaScript code:
// devServer.js

var webpack = require('webpack');
var WebpackDevServer = require('webpack-dev-server');
var config = require('./webpack.config');

new WebpackDevServer(webpack(config), {
  publicPath: config.output.publicPath,
  hot: true,
  historyApiFallback: true,
}).listen(8080, 'localhost', function (err, result) {
  if (err) {
    console.log(err);
  }
  console.log('Listening at localhost:8080');
});
and my production one, which breaks out all my dependencies into a vendor.js file so users cache it since that rarely changes. SASS/ CSS is pulled out into a separate file, and I use HtmlWebPackPlugin to generate a new index.html with all the correct file names. All generated files go into a /dist directory.

JavaScript code:
// weboapck.production.js
const path    = require('path');
const webpack = require('webpack');
const autoprefixer = require('autoprefixer')
const HtmlWebpackPlugin = require('html-webpack-plugin');
const ExtractTextPlugin = require("extract-text-webpack-plugin");
const pkg = require('./package.json');
const deps = Object.keys(pkg.dependencies);


const sassLoaders = [
    'css-loader',
    'postcss-loader',
    'sass-loader?includePaths[]=' + path.resolve(__dirname, './src')
]

module.exports = {
    entry: {
        bundle: './src/client.js',
        vendor: deps
    },
    resolve: {
        modulesDirectories: ['node_modules', 'shared'],
        extensions:         ['', '.js', '.jsx']
    },
    output: {
        path:       path.join(__dirname, 'dist'),
        filename:   '[name].[chunkhash].js',
        chunkFilename: '[chunkhash].js',
        publicPath: '/'
    },
    devtool: 'cheap-module-source-map',
    module: {
        loaders: [
            {
            test:    /\.jsx?$/,
            exclude: /node_modules/,
            loaders: ['babel']
        },
        { 
            test: /\.scss$/,
            loader: ExtractTextPlugin.extract(
                'style-loader',
                sassLoaders
            ) 
        },
        { 
            test: /\.(png|jpg)$/,
            loader: 'file-loader?name=[path][hash].[ext]' 
        },
        ]
    },
    plugins: [
        new ExtractTextPlugin("style.css", {allChunks: false}),
        new webpack.DefinePlugin({
            'process.env': {
                NODE_ENV: '"production"'
            }
        }),
        new webpack.optimize.CommonsChunkPlugin({
            names: ['vendor', 'manifest']
        }),
        new webpack.optimize.UglifyJsPlugin({
            compress: {
                warnings: false
            }
        }),
        new HtmlWebpackPlugin({
            chunksSortMode: 'dependency',
            title: 'YOUR TITLE HERE',
            template: 'appTemplate.ejs', 
            inject: 'body' 
        }),
    ]
};
I run a production build with:
code:
NODE_ENV=production webpack -p --progress --colors  --config webpack.production.js
Also, read this: http://survivejs.com/webpack/introduction/

Lumpy fucked around with this message at 14:32 on Aug 15, 2016

Depressing Box
Jun 27, 2010

Half-price sideshow.
On the topic of Webpack, this looks pretty cool.

Adbot
ADBOT LOVES YOU

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

:monocle:

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply